Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3367 closed defect (fixed)

Tor 0.2.3.x segfaults on SIGNAL TERM

Reported by: rransom Owned by: nickm
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I have a core dump, and will extract a backtrace tomorrow.

This may have been caused by Vidalia connecting to this Tor instance, and it may be the same crash that I reported on #2001 for the test Vidalia Bundle for Windows.

Child Tickets

Change History (8)

comment:1 Changed 8 years ago by rransom

Summary: Tor 0.2.3.x segfaults on exitTor 0.2.3.x segfaults on SIGNAL TERM
(gdb) bt
#0  0x0000000000450f65 in flush_buf (s=11, buf=0x0, sz=0, 
    buf_flushlen=0x8026d20f0) at buffers.c:828
#1  0x0000000000476168 in connection_handle_write (conn=0x8026d20c0, force=1)
    at connection.c:3257
#2  0x0000000000487b2b in handle_control_signal (conn=0x8026d20c0, len=Variable "len" is not available.
)
    at control.c:1282
#3  0x000000000048a69f in connection_control_process_inbuf (conn=0x8026d20c0)
    at control.c:3171
#4  0x000000000047553d in connection_handle_read_cb (bufev=Variable "bufev" is not available.
)
    at connection.c:2955
#5  0x0000000800ab1a8b in bufferevent_run_deferred_callbacks_locked ()
   from /usr/local/lib/event2/libevent-2.0.so.5
#6  0x0000000800aaa2c1 in event_base_loop ()
   from /usr/local/lib/event2/libevent-2.0.so.5
#7  0x0000000000409e33 in do_main_loop () at main.c:1789
#8  0x000000000040a0c5 in tor_main (argc=3, argv=Variable "argv" is not available.
) at main.c:2464
#9  0x0000000000408d0e in _start ()

I ended Tor by sending the SIGNAL TERM control-port command, which is exactly how Vidalia would have ended my Tor instance on Windows.

I just sent SIGNAL TERM again, with the SIGNAL control-port event enabled, and Tor segfaulted before my control-port client received the 250 OK response:

signal term
% Connection to mytorctl closed by foreign host.

As you can see from the backtrace, I configured Tor with --enable-bufferevents. This crash occurred on branch git://git.torproject.org/rransom/tor.git loud-hs-serv-pk-operations (closest to commit 9ac2f63e0f3f1fd333b23ee6e6c02ae7cf0f71d2 (‘Unbreak the build’) on master).

comment:2 in reply to:  1 ; Changed 8 years ago by nickm

Owner: changed from rransom to nickm
Status: newassigned

Replying to rransom:

(gdb) bt
#0  0x0000000000450f65 in flush_buf (s=11, buf=0x0, sz=0, 
    buf_flushlen=0x8026d20f0) at buffers.c:828

This is telling; buf shouldn't be 0 if flush_buf has a hope of working.

Also, we shouldn't be using flush_buf when bufferevents are enabled...

#1 0x0000000000476168 in connection_handle_write (conn=0x8026d20c0, force=1)

at connection.c:3257

#2 0x0000000000487b2b in handle_control_signal (conn=0x8026d20c0, len=Variable "len" is not available.
)

at control.c:1282

Oho, here's the trouble; handle_control_signal is calling connection_handle_write directly, when it's a buf_t-only function!

Best have a connection_flush that does the right thing.

comment:3 in reply to:  2 ; Changed 8 years ago by rransom

Replying to nickm:

Oho, here's the trouble; handle_control_signal is calling connection_handle_write directly, when it's a buf_t-only function!

Perhaps connection_handle_write shouldn't be defined when bufferevents are enabled.

comment:4 in reply to:  3 ; Changed 8 years ago by nickm

Status: assignedneeds_review

Replying to rransom:

Replying to nickm:

Oho, here's the trouble; handle_control_signal is calling connection_handle_write directly, when it's a buf_t-only function!

Perhaps connection_handle_write shouldn't be defined when bufferevents are enabled.

Maybe. The idea behind the current architecure is that you should be able to have bufferevents on only some connection types. I did that to make it easier to debug. At some point in the 0.2.3.x series, though, we should consider a switch.

Anyways, have a look at branch bug3367 in my public repo.

comment:5 in reply to:  4 Changed 8 years ago by rransom

Replying to nickm:

Anyways, have a look at branch bug3367 in my public repo.

That branch works for me (i.e. SIGNAL TERM ends Tor properly, without a segfault).

comment:6 Changed 8 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Great; merging.

comment:7 Changed 7 years ago by nickm

Keywords: tor-client added

comment:8 Changed 7 years ago by nickm

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