Assertion when upstream connection is established (with event handled by thread 
A) and immediately disconnected (handled by thread B)
-------------------------------------------------------------------------------------------------------------------------------------

                 Key: TS-1032
                 URL: https://issues.apache.org/jira/browse/TS-1032
             Project: Traffic Server
          Issue Type: Bug
          Components: Core, HTTP
    Affects Versions: 3.1.1
         Environment: Linux 32bit CentOS 5.4. Pre-open source version of ATS.
            Reporter: Uri Shachar


This happened twice on a very old version of ATS (pre opensource code), but it 
looks like it can happen in current ATS as well (it's a very rare race 
condition, haven't been able to reproduce).

Scenario:
        1)      Client request arrives, handled by TS thread 1 and is reenabled 
by a plugin (Inside a continuation called by ContSched)
        2)      TS thread 2 starts to connect upstream
        3)      A client disconnection event is placed in thread 1 queue.
        4)      A successful connection event is placed in thread 2 queue.
        5)      Thread 1 starts to handle pending events (setting cur_time to X)
        6)      Thread 2 starts to handle pending events (setting cur_time to 
Z=X+Y)
        7)      Thread 2 handles the connection established event (setting 
server_first_connect to Z)
        8)      Thread 1 handles the client disconnection event - Getting a 
negative wait and asserting...

Sample stack trace:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xe3131b90 (LWP 14584)]
0xffffe410 in __kernel_vsyscall ()
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x007e2df0 in raise () from /lib/libc.so.6
#2  0x007e484e in abort () from /lib/libc.so.6
#3  0x08427612 in ink_die_die_die (retval=1) at 
/usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_error.cc:45
#4  0x08427778 in ink_fatal_va (return_code=1, message_format=0xe312ee1f 
"/tmp/ushachar-rpmbuild/BUILD/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:5572: 
failed assert `wait >= 0`", ap=0xe312ee08 "\002") at 
/usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_error.cc:100
#5  0x084277d3 in ink_fatal (return_code=1, message_format=0xe312ee1f 
"/tmp/ushachar-rpmbuild/BUILD/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:5572: 
failed assert `wait >= 0`") at 
/usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_error.cc:111
#6  0x08424508 in _ink_assert (a=0x853db72 "wait >= 0", f=0x853ab3c 
"/tmp/ushachar-rpmbuild/BUILD/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc", 
l=5572) at /usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_assert.cc:27
#7  0x082f2505 in HttpSM::mark_server_down_on_client_abort (this=0xb622ece0) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:5572
#8  0x082f6080 in HttpSM::state_watch_for_client_abort (this=0xb622ece0, 
event=3, data=0x7e0e2a88) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:1148
#9  0x082fad0f in HttpSM::main_handler (this=0xb622ece0, event=3, 
data=0x7e0e2a88) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:3213
#10 0x0810a07b in Continuation::handleEvent (this=0xb622ece0, event=3, 
data=0x7e0e2a88) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/Continuation.h:85
#11 0x083ab348 in read_signal_and_update (event=3, vc=0x7e0e2a30) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:262
#12 0x083ab3fe in read_signal_done (event=3, nh=0xa339b28, vc=0x7e0e2a30) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:300
#13 0x083ab44f in read_signal_error (nh=0xa339b28, vc=0x7e0e2a30, lerrno=104) 
at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:324
#14 0x083ae1c5 in read_from_net (nh=0xa339b28, vc=0x7e0e2a30, thread=0xa32e490) 
at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:783
#15 0x083ae5a7 in UnixNetVConnection::net_read_io (this=0x7e0e2a30, 
nh=0xa339b28, lthread=0xa32e490) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:1059
#16 0x083adced in NetHandler::mainNetEvent (this=0xa339b28, event=5, 
e=0xa1ab810) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:1272
#17 0x0810a07b in Continuation::handleEvent (this=0xa339b28, event=5, 
data=0xa1ab810) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/Continuation.h:85
#18 0x083a19ac in EThread::process_event (this=0xa32e490, e=0xa1ab810, 
calling_code=5) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixEThread.cc:132
#19 0x0839f800 in EThread::execute (this=0xa32e490) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixEThread.cc:315
#20 0x083b4f9a in spawn_thread_internal (a=0xa385360) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixThread.cc:71
#21 0x009065ab in start_thread () from /lib/libpthread.so.0
#22 0x0088bcfe in clone () from /lib/libc.so.6

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to