Opened 12 years ago

Last modified 7 years ago

#561 closed defect (Fixed)

tor segfaults in libevent

Reported by: Falo Owned by: nickm
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.0.9-alpha
Severity: Keywords:
Cc: Falo, nickm, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

tor-0.2.0.11-alpha as well as tor-0.2.0.12-alpha did core dump after about one week of operation on my Debian “lenny” exit gw.

1.) backtrace for 0.2.0.11

Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7f3d4c2 in event_tree_RB_REMOVE_COLOR () from /usr/lib/libevent-1.3d.so.1
(gdb) bt
#0 0xb7f3d4c2 in event_tree_RB_REMOVE_COLOR () from /usr/lib/libevent-1.3d.so.1
#1 0xb7f3d7b7 in event_tree_RB_REMOVE () from /usr/lib/libevent-1.3d.so.1
#2 0xb7f3dc0b in ?? () from /usr/lib/libevent-1.3d.so.1
#3 0x0812b614 in ?? ()
#4 0xa3f22300 in ?? ()
#5 0x0810cd0d in ?? ()
#6 0x08125ea0 in evdns_log_fn ()
#7 0xb7e14977 in AES_encrypt () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#8 0xa3f22300 in ?? ()
#9 0xbfccc848 in ?? ()
#10 0xb7f3ded1 in event_del () from /usr/lib/libevent-1.3d.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

2.) backtrace for 0.2.0.12

Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7f6e4b6 in event_tree_RB_REMOVE_COLOR () from /usr/lib/libevent-1.3d.so.1
(gdb) bt
#0 0xb7f6e4b6 in event_tree_RB_REMOVE_COLOR () from /usr/lib/libevent-1.3d.so.1
#1 0xb7f6e7b7 in event_tree_RB_REMOVE () from /usr/lib/libevent-1.3d.so.1
#2 0xb7f6ec0b in ?? () from /usr/lib/libevent-1.3d.so.1
#3 0x0813a614 in ?? ()
#4 0xa19c9398 in ?? ()
#5 0x0811beed in ?? ()
#6 0x081351e0 in evdns_log_fn ()
#7 0xa6a5f390 in ?? ()
#8 0x36dbdff4 in ?? ()
#9 0x0813a478 in ?? ()
#10 0xb7f7d170 in ?? () from /usr/lib/libevent-1.3d.so.1
#11 0x0813a478 in ?? ()
#12 0xa19c9398 in ?? ()
#13 0xbf90b498 in ?? ()
#14 0xb7f6eed1 in event_del () from /usr/lib/libevent-1.3d.so.1
Backtrace stopped: frame did not save the PC
(gdb)

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

Child Tickets

Change History (12)

comment:1 Changed 12 years ago by Falo

OpenBSD_malloc_Linux.c solves this issue.

comment:2 Changed 12 years ago by nickm

Are there any more useful stack traces coming out of this? The ones above seem almost sure to be corrupted,
since event_del should be unable to invoke any callbacks in Tor, including any that would invoke AES_encrypt.

Of course, if the openbsd_malloc_linux.c trick solves it, it could conceivably be some bad behavior on out-of-memory.
But that seems really unlikely.

comment:3 Changed 12 years ago by Falo

I'm sorry, there aren't any more stack traces. If required, I could use glibc malloc() again and wait for Tor crashing.

comment:4 Changed 11 years ago by arma

Looking forward to hearing if 0.2.1.x with glibc malloc sees the same problems. :)

comment:5 Changed 11 years ago by Falo

it appears to be fixed with v0.2.1.2-alpha (r15383). At least process size appears to stay constantly at about 360 MB. Keep you posted again after about one week of operation...

comment:6 Changed 11 years ago by Falo

v0.2.1.2-alpha using glibc malloc() is still memory leaking. Meanwhile process size grew to 410 MB. Keep you posted :-)

comment:7 Changed 11 years ago by Falo

432 MB

comment:8 Changed 11 years ago by Falo

the bug appears to be fixed. v0.2.1.2-alpha didn't crash after three weeks running with glibc malloc. Tor's working set finally grew to 481 MB.

comment:9 Changed 11 years ago by nickm

If you want to experiment, try out 0.2.1.2-alpha with an OpenSSL 0.9.9 snapshot; the memory usage may be far lower.

comment:10 Changed 11 years ago by nickm

This seems to have been fixed, I guess. No new info since July.

comment:11 Changed 11 years ago by nickm

flyspray2trac: bug closed.

comment:12 Changed 7 years ago by nickm

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