Opened 10 years ago

Closed 10 years ago

Last modified 7 years ago

#1315 closed defect (invalid)

Unable to get Tor to compile using OpenSSL 1.0.0-beta5 on Debian Lenny

Reported by: narr Owned by:
Priority: Low Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: narr, Sebastian, arma, nickm, erinn, weasel Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arma)

My high bandwidth exit node crashes every few days - network timeouts, unable to connect
(for server config, see below). Using remote console, I can see a lot of output being
printed; from my limited Linux knowledge the following lines look most interesting:

oom-killer: gfp_mask=0xd0, order=1

[<c013f177>] out_of_memory+0x25/0x13a
[<c0140655>] alloc_pages+0x1f5/0x275
[<c015626e>] cache_alloc_refill+0x297/0x493
[<c015603a>] cache_alloc_refill+0x63/0x493
[<c0155fbe>] kmem_cache_alloc+0x3b/0x54
[<c0118d7a>] copy_process+0xa5/0x10ae
[<c0155fcd>] kmem_cache_alloc+0x4a/0x54
[<c028a288>] _spin_lock_irq+0x8/0x18
[<c01295bb>] alloc_pid+0x1fc/0x219
[<c0119fe8>] do_fork+0x91/0x17a
[<c01239a5>] sigprocmask+0xcc/0xd2
[<c0102c06>] sys_clone+0x28/0x2d
[<c0104883>] syscall_call+0x7/0xb

Sometimes I also get:

<c01506c2>] read_swap_cache_async+0x2f/0xac

[<c01461b2>] swapin_readahead+0x3a/0x58
[<c0148654>] handle_mm_fault+0xa62/0xfa3
[<c015844e>] do_truncate+0x6b/0x75
[<c0141f78>] release_pages+0x143/0x14b
[<c0111889>] do_page_fault+0x6af/0xb76
[<c0325c7c>] flush_window+0x4b/0x94
[<c014b7bc>] unmap_region+0xe1/0xf0
[<c0155c0d>] kmem_cache_free+0x44/0x7d
[<c011e9ea>] sys_gettimeofday+0x27/0x53
[<c01111da>] do_page_fault+0x0/0xb76
[<c0104a0f>] error_code+0x2b/0x30

So, after reading the FAQ, I'm now trying to build Tor with OpenSSL 1.0.0-beta5 manually.
These are the steps I performed:

  • I left the Debian OpenSSL package installed and used configure, make and make install to

install OpenSSL1.0.0-beta5 to /usr/local/ssl

Tor and tried to configure it:

./configure --enable-openbsd-malloc --enable-static-openssl --with-openssl-dir=/usr/local/ssl

Then, I used debuild -rfakeroot -uc -us and installed the package, but Tor still seems to be
using OpenSSL 0.9.8:

[notice] Tor (git-e43253ba9e9430ea) opening log file.
[notice] OpenSSL OpenSSL 0.9.8g 19 Oct 2007 [90807f] looks like it's older than 0.9.8l,
but some vendors have backported 0.9.8l's renegotiation code to earlier versions. #
I'll set SSL3_FLAGS just to be safe.


OPENSSL = /usr/local/ssl/bin/openssl
TOR_OPENSSL_LIBS = /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a

Sebastian suggested to also compile libevent statically, but I'm not sure how: The
option --with-libevent-dir wants me to specify a directory, whereas I only have
libevent libraries directly inside /usr/lib.
Also, is it on purpose that configure accepts both --with-openssl-dir=/usr/local/ssl
and --with-openssl-dir=/usr/local/ssl/bin ?

You can find me on IRC (nick "narr").

Debian Lenny DomU with 2.6.18-6-xen-686 etch Kernel
~5MB/s bandwidth

free -m (no tor running)

total used free shared buffers cached

Mem: 1640 1625 15 0 14 1200
-/+ buffers/cache: 410 1229
Swap: 1023 0 1023

[Automatically added by flyspray2trac: Operating System: Other Linux]

Child Tickets

Change History (9)

comment:1 Changed 10 years ago by erinn

Since it sounds like you're using the Debian source, you'll need to modify the configure line in debian/rules with the right options (rules is a Makefile within the debian/ directory). Once you do that and rebuild, does it use the correct version?

comment:2 Changed 10 years ago by narr

Thanks for telling me what lines to modify exactly on IRC, too ( ).

This should be clarified in the documentation. :)

comment:3 Changed 10 years ago by nickm

Milestone: Tor: 0.2.2.x-final

comment:4 Changed 10 years ago by arma

Description: modified (diff)

Is this a bug better suited for debian's bugtracker? It isn't getting much attention here.

comment:5 Changed 10 years ago by nickm

Maybe; it depends how the deb gets built. If the deb is telling Tor to look in the wrong place, it's the deb's fault. If Tor is told to look in the right place and we're grabbing the wrong openssl, it's our fault.

I suspect this might be related to the brokenness in our build process where having a functional openssl in a system dir can keep us from realizing that we needed to use rpath to get the openssl we really wanted.

comment:6 Changed 10 years ago by weasel

arma: there is no debian bug here. The package does not support building against random librarys, not should it.

re general: I do wonder how the submitter came from "kernel prints backtraces in its log" to "let's rebuild tor with a newer libssl" tho. If anything these logs might indicate that vm.min_free_kbytes could perhaps be raised a bit.

comment:7 Changed 10 years ago by weasel

Resolution: Noneinvalid
Status: newclosed

It's not entirely clear what this bug report is about anyway.

If it is about not being able to build the debian package against non-standard libs then the answer is: modify debian/rules etc accordingly.

If the answer is: my linux kernel spews weird backtraces to kern.log then this trac is not the right place.

If the problem is indeed about building Tor itself against a non-default libssl then it should be reported as a new clear and concise bug report.

For now I'm closing this report.

comment:8 Changed 10 years ago by nickm

(If it's a non-default-openssl problem, then maybe a comment on bug #1354 would be the right place to put it.)

comment:9 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.