[
https://issues.apache.org/jira/browse/TS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166513#comment-13166513
]
Alan M. Carroll commented on TS-857:
------------------------------------
Where would it record the pending event? The presumption is that the only other
thread that might close it is the one that will process the event.
But the real issue is that sometimes the lock is dropped between the time the
lock try is done and the event is scheduled, leading to scheduling on the null
thread. If you look at TS-934 you can see how that issue is handled there, but
even that's not sufficient because normal VC processing from
NetHandler::mainNetEvent does not lock the VCs, so there isn't any way do
anything safely in this case.
> Crash Report: HttpTunnel::chain_abort_all -> HttpServerSession::do_io_close
> -> UnixNetVConnection::do_io_close
> --------------------------------------------------------------------------------------------------------------
>
> Key: TS-857
> URL: https://issues.apache.org/jira/browse/TS-857
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
> Affects Versions: 3.1.0
> Environment: in my branch that is something same as 3.0.x
> Reporter: Zhao Yongming
> Assignee: weijin
> Fix For: 3.1.3
>
> Attachments: ts-857.diff, ts-857.diff
>
>
> here is the bt from the crash, some of the information is missing due to we
> have not enable the --enable-debug configure options.
> {code}
> [New process 7532]
> #0 ink_stack_trace_get (stack=<value optimized out>, len=<value optimized
> out>, signalhandler_frame=<value optimized out>)
> at ink_stack_trace.cc:68
> 68 fp = (void **) (*fp);
> (gdb) bt
> #0 ink_stack_trace_get (stack=<value optimized out>, len=<value optimized
> out>, signalhandler_frame=<value optimized out>)
> at ink_stack_trace.cc:68
> #1 0x00002ba641dccef1 in ink_stack_trace_dump (sighandler_frame=<value
> optimized out>) at ink_stack_trace.cc:114
> #2 0x00000000004df020 in signal_handler (sig=<value optimized out>) at
> signals.cc:225
> #3 <signal handler called>
> #4 0x00000000006a1ea9 in UnixNetVConnection::do_io_close (this=0x1cc9bd20,
> alerrno=<value optimized out>)
> at ../../iocore/eventsystem/I_Lock.h:297
> #5 0x000000000051f1d0 in HttpServerSession::do_io_close
> (this=0x2aaab0042c80, alerrno=20600) at HttpServerSession.cc:127
> #6 0x000000000056d1e9 in HttpTunnel::chain_abort_all (this=0x2aabeeffdd70,
> p=0x2aabeeffdf68) at HttpTunnel.cc:1300
> #7 0x00000000005269ca in HttpSM::tunnel_handler_ua (this=0x2aabeeffc070,
> event=104, c=0x2aabeeffdda8) at HttpSM.cc:2987
> #8 0x0000000000571dfc in HttpTunnel::consumer_handler (this=0x2aabeeffdd70,
> event=104, c=0x2aabeeffdda8) at HttpTunnel.cc:1232
> #9 0x0000000000572032 in HttpTunnel::main_handler (this=0x2aabeeffdd70,
> event=1088608784, data=<value optimized out>)
> at HttpTunnel.cc:1456
> #10 0x00000000006a6307 in write_to_net_io (nh=0x2aaaab12d688, vc=0x1cc876e0,
> thread=<value optimized out>)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #11 0x000000000069ce97 in NetHandler::mainNetEvent (this=0x2aaaab12d688,
> event=<value optimized out>, e=0x171c1ed0) at UnixNet.cc:405
> #12 0x00000000006cddaf in EThread::process_event (this=0x2aaaab12c010,
> e=0x171c1ed0, calling_code=5) at I_Continuation.h:146
> #13 0x00000000006ce6bc in EThread::execute (this=0x2aaaab12c010) at
> UnixEThread.cc:262
> #14 0x00000000006cd0ee in spawn_thread_internal (a=0x171b58f0) at Thread.cc:88
> #15 0x0000003c33c064a7 in start_thread () from /lib64/libpthread.so.0
> #16 0x0000003c330d3c2d in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x40e2b790:
> rip = 0x2ba641dccdf3 in ink_stack_trace_get(void**, int, int)
> (ink_stack_trace.cc:68); saved rip 0x2ba641dccef1
> called by frame at 0x40e2bbe0
> source language c++.
> Arglist at 0x40e2b770, args: stack=<value optimized out>, len=<value
> optimized out>, signalhandler_frame=<value optimized out>
> Locals at 0x40e2b770, Previous frame's sp is 0x40e2b790
> Saved registers:
> rbx at 0x40e2b778, rbp at 0x40e2b780, rip at 0x40e2b788
> (gdb)
> {code}
--
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
