trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gksalil@gmail.com <gksa...@gmail.com>
Subject Re: Crash - looks like 1765 -
Date Sat, 07 Jul 2018 01:02:57 GMT


On 2018/07/06 16:10:52, "xuchao@Gmail" <xuchao@gmail.com> wrote: 
> I'm try to fix the TVC double close bug with https://github.com/apache/trafficserver/pull/1765
.
> 
> But the PR#1765 does not fix it and makes new crash.
> 
> The 2nd solution to fix the issue https://github.com/apache/trafficserver/pull/2907
> .
> 
> That's all about the bug.
> 
> - oknet xu
> 
> 发自我的 iPhone
> 
> > 在 2018年6月29日,00:23,gksalil@gmail.com <gksalil@gmail.com> 写道:
> > 
> > 
> > 
> >> On 2018/05/22 08:56:56, Chao Xu <oknet@apache.org> wrote: 
> >> Hi salil,
> >> 
> >> please try to apply
> >> https://github.com/apache/trafficserver/commit/49c903b0c13a2fd2c085325f6942326c4f9c926a
> >> .
> >> 
> >> - Oknet
> >> 
> >> 2018-05-14 22:03 GMT+08:00 salil GK <gksalil@gmail.com>:
> >> 
> >>> Hello
> >>> 
> >>>   I am using ATS 6.2.2 and found a crash happening in
> >>> TransformVConnection::do_io_close:467. This looks like bug 1765. But
> >>> while looking at that bug - it looks like that defect is not resolved
> >>> completely.
> >>> 
> >>> Stack trace from my machine is as follows
> >>> 
> >>>>>> 
> >>> 
> >>> #1 0x00007f42727282a8 in _Unwind_Backtrace () from
> >>> /lib/x86_64/libgcc_s.so.1
> >>> #2 0x00007f427245fa88 in backtrace () from /lib/x86_64/libc.so.6
> >>> #3 0x00007f4274c9bd7f in ink_stack_trace_dump () at ink_stack_trace.cc:61
> >>> #4 0x00007f4274c9e2f3 in signal_crash_handler (signo=11) at signals.cc:180
> >>> #5 0x00005575fdf9f68a in crash_logger_invoke (signo=11,
> >>> info=0x7f427174e630, ctx=0x7f427174e500) at Crash.cc:169
> >>> #6 <signal handler called>
> >>> #7 0x00000000000000b8 in ?? ()
> >>> #8 0x00005575fdff8b5e in TransformVConnection::do_io_close
> >>> (this=0x5575ff57eb20, error=20600) at Transform.cc:467
> >>> #9 0x00005575fe08d691 in HttpTunnel::chain_abort_all
> >>> (this=0x7f426a9d54e8, p=0x7f426a9d56e8) at HttpTunnel.cc:1444
> >>> #10 0x00005575fe03761a in HttpSM::tunnel_handler_post_ua
> >>> (this=0x7f426a9d41b0, event=104, p=0x7f426a9d56e8) at HttpSM.cc:3505
> >>> #11 0x00005575fe08cdeb in HttpTunnel::producer_handler
> >>> (this=0x7f426a9d54e8, event=104, p=0x7f426a9d56e8) at
> >>> HttpTunnel.cc:1240
> >>> #12 0x00005575fe08dc3b in HttpTunnel::main_handler
> >>> (this=0x7f426a9d54e8, event=104, data=0x5575ff201e18) at
> >>> HttpTunnel.cc:1623
> >>> #13 0x00005575fdfa282f in Continuation::handleEvent
> >>> (this=0x7f426a9d54e8, event=104, data=0x5575ff201e18) at
> >>> ../iocore/eventsystem/I_Continuation.h:153
> >>> #14 0x00005575fe1f9a08 in read_signal_and_update (event=104,
> >>> vc=0x5575ff201d00) at UnixNetVConnection.cc:148
> >>> #15 0x00005575fe1f9da1 in read_signal_done (event=104,
> >>> nh=0x7f4271858cd0, vc=0x5575ff201d00) at UnixNetVConnection.cc:209
> >>> #16 0x00005575fe1fa61f in read_from_net (nh=0x7f4271858cd0,
> >>> vc=0x5575ff201d00, thread=0x7f4271855010) at UnixNetVConnection.cc:359
> >>> #17 0x00005575fe1fc78a in UnixNetVConnection::net_read_io
> >>> (this=0x5575ff201d00, nh=0x7f4271858cd0, lthread=0x7f4271855010) at
> >>> UnixNetVConnection.cc:933
> >>> #18 0x00005575fe1f0bc1 in NetHandler::mainNetEvent
> >>> (this=0x7f4271858cd0, event=5, e=0x5575ff06ec40) at UnixNet.cc:513
> >>> #19 0x00005575fdfa282f in Continuation::handleEvent
> >>> (this=0x7f4271858cd0, event=5, data=0x5575ff06ec40) at
> >>> ../iocore/eventsystem/I_Continuation.h:153
> >>> #20 0x00005575fe21fe1f in EThread::process_event (this=0x7f4271855010,
> >>> e=0x5575ff06ec40, calling_code=5) at UnixEThread.cc:148
> >>> #21 0x00005575fe22037c in EThread::execute (this=0x7f4271855010) at
> >>> UnixEThread.cc:275
> >>> #22 0x00005575fe21f312 in spawn_thread_internal (a=0x5575ff03ee10) at
> >>> Thread.cc:86
> >>> #23 0x00007f4272ecb633 in start_thread (arg=0x7f4271753700) at
> >>> pthread_create.c:463
> >>> #24 0x00007f427245198f in clone () from /lib/x86_64/libc.so.6
> >>> 
> >>> <<<<<<
> >>> 
> >>> What can I do to handle this ...  Can I apply the solution mentioned
> >>> in that bug in my 6.2.2 source.
> >>> 
> >>> Thanks in advance
> >>> ~S
> >>> 
> >> 
> >> 
> >> 
> >> -- 
> >> - Oknet Xu
> >> 
> > 
> > Do you have pointers on what circumstance, this issue could happen ? 
> 

- Thanks for the reply. Is there any way I can reproduce this issue. 
~S

Mime
View raw message