[ https://issues.apache.org/jira/browse/TS-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom reassigned TS-1032: --------------------------------- Assignee: Leif Hedstrom > 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 > Assignee: Leif Hedstrom > Fix For: 3.1.2 > > Attachments: wait_patch.diff > > Original Estimate: 1h > Remaining Estimate: 1h > > 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