HardwareAccel isn't used

[udo]

Log shows me:

[info] crypto_global_init(): Initializing OpenSSL via tor_tls_init().

but crypto.c says:

if (useAccel < 0) {

log_info(LD_CRYPTO, "Initializing OpenSSL via tor_tls_init().");

}
if (useAccel > 0) {

log_info(LD_CRYPTO, "Initializing OpenSSL engine support.");
ENGINE_load_builtin_engines();
if (!ENGINE_register_all_complete())

return -1;

So no HardwareAccel even though torrc says:

HardwareAccel 1

This is Fedora 10 on VIA EK8000. Tor 0.2.0.32, built with source and spec from tor.eff site.

[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]

[udo]

# openssl engine
(padlock) VIA PadLock (no-RNG, ACE)
(dynamic) Dynamic engine loading support

Patched openssl, of course.

[nickm]

I can't for the life of me figure out what is calling tor_tls_init before crypto_global_init() gets called. I've
tried to reproduce this on 0.2.0.32-dev, 0.2.0.32, and trunk, and had no luck. crypto_global_init() was called from
tor_init each time.

Can you use gdb to set a breakpoint inside crypto_global_init(), run Tor, and check the stack trace to see the first
place where crypto_global_init() is called for you?

Posting your torrc might be useful too.

[udo]

torrc:

SocksPort 9050 # what port to open for local application connections
SocksListenAddress 127.0.0.1 # accept connections only from localhost
DataDirectory /var/lib/tor
ControlPort 9051
HashedControlPassword blabla
Nickname blabla
Address blabla
ContactInfo Random Person blabla
ORPort 9001
ExitPolicy reject *:* # middleman only -- no exits allowed
BandwidthRate 20 KB
BandwidthBurst 21000
HardwareAccel 1
AccountingStart day 12:21
AccountingMax 2 GB
User _tor

Is there a quick gdb howto for the asked breakpoint test or is it very easy to figure out?

[nickm]

Start gdb with "gdb path/to/tor"

Then say "break crypto.c:180", where instead of 180, you say the line where you want to put a breakpoint.

Then say "run". If you start Tor with command-line arguments, give them after this "run".

GDB will stop when it hits the breakpoint. When this happens, say "bt" to get a stack trace.

[udo]

(gdb) run -f /etc/tor/torrc --pidfile /var/run/tor/tor.pid
Starting program: /usr/bin/tor -f /etc/tor/torrc --pidfile /var/run/tor/tor.pid
[Thread debugging using libthread_db enabled]
Jan 21 16:10:07.640 [notice] Tor v0.2.0.32 (r17346). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686)
Jan 21 16:10:07.648 [notice] Initialized libevent version 1.4.5-stable using method epoll. Good.
Jan 21 16:10:07.652 [notice] Opening OR listener on 0.0.0.0:9001
Jan 21 16:10:07.656 [notice] Opening Socks listener on 127.0.0.1:9050
Jan 21 16:10:07.659 [notice] Opening Control listener on 127.0.0.1:9051
[New Thread 0xb7ff1a40 (LWP 585)]

Breakpoint 1, crypto_global_init (useAccel=-1) at crypto.c:180
180 _crypto_global_initialized = 1;
(gdb) bt
#0 crypto_global_init (useAccel=-1) at crypto.c:180
#1 0x080d95bc in tor_tls_init () at tortls.c:304
#2 0x080d9972 in tor_tls_context_new (identity=0x811e618, key_lifetime=7200) at tortls.c:530
#3 0x080b104f in init_keys () at router.c:515
#4 0x08094f6b in accounting_set_wakeup_time () at hibernate.c:462
#5 configure_accounting (now=1232550607) at hibernate.c:361
#6 0x080641ea in options_act () at config.c:1227
#7 set_options (new_val=0x8115530, msg=0xbffff6a4) at config.c:753
#8 0x08064e10 in options_init_from_torrc (argc=5, argv=0xbffff8d4) at config.c:3704
#9 0x0809632d in tor_init (argc=5, argv=0xbffff8d4) at main.c:1802
#10 0x080994e7 in tor_main (argc=5, argv=0xbffff8d4) at main.c:1985
#11 0x080c6fe7 in main (argc=1, argv=0x8000) at tor_main.c:29

[nickm]

Thanks! This should be fixed in r18210.

[udo]

Where can I see that patch/diff so I can test the change?

Thanks in advance for the info.

(full tree of 2.0.32 with patch is also OK)

[nickm]

You could check out the latest revision from subversion:

​http://www.torproject.org/documentation#Developers

This patch hasn't been backported to the stable branch yet, since we're trying to do a stable release today, and this
needs more testing.

[arma]

I suspect what you're looking for is here:
​http://archives.seul.org/or/cvs/Jan-2009/threads.html
specifically,
​http://archives.seul.org/or/cvs/Jan-2009/msg00373.html

[udo]

Thanks!
Unfortunately the patch doesn't work right away; after some fiddling I run into issues with crypto_seed_rng that was changed after 2.0.32 was released (I guess).
I think I'll have to wait for tor 2.0.33. (with hopefully this fix)

[nickm]

No, the fix for this one will have to go into 0.2.0.34; 0.2.0.33 is coming out today, and there isn't time to test
this fix enough.

[udo]

0.2.0.34 does not mention bug 907?

[arma]

Correct. I don't think we're going to backport it to 0.2.0 after all, since
we're trying to reduce the number of changes we make to the 'stable' release.

0.2.1.12-alpha has your fix though.

[udo]

How stable is 0.2.1.12 if that isn't a stable release?
In other words, with respect for the decision, what will I get?

[nickm]

Alpha releases come with all the guarantees that the stable series does, which is to say: "no guarantees at all". ;) We
try hard to make sure they all work, but the fact that alphas often have new features or complex fixes (like this one)
means that they are likelier to have new bugs than releases in the stable series.

That said, I run the alphas, and they works for me, usually. If they don't work for you, it should be easy to move
back to 0.2.0.x until the next version of 0.2.1.x comes out.

[nickm]

flyspray2trac: bug closed.