You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by salil GK <gk...@gmail.com> on 2018/05/14 14:03:44 UTC
Crash - looks like 1765 -
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
Re: Crash - looks like 1765 -
Posted by salil GK <gk...@gmail.com>.
Thanks Chao, I will try this patch and see if the issue happens again.
On 22 May 2018 at 14:26, Chao Xu <ok...@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 <gk...@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
Re: Crash - looks like 1765 -
Posted by gk...@gmail.com,
gk...@gmail.com.
On 2018/07/06 16:10:52, "xuchao@Gmail" <xu...@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 <gk...@gmail.com> 写道：
> >
> >
> >
> >> On 2018/05/22 08:56:56, Chao Xu <ok...@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 <gk...@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
Re: Crash - looks like 1765 -
Posted by Leif Hedstrom <zw...@apache.org>.
> On Jul 6, 2018, at 10:10 AM, xuchao@Gmail <xu...@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.
Does any of this need to go into 7.1.x or 8.0.x ?
Cheers,
— leif
>
> - oknet xu
>
> 发自我的 iPhone
>
>> 在 2018年6月29日，00:23，gksalil@gmail.com <gk...@gmail.com> 写道：
>>
>>
>>
>>> On 2018/05/22 08:56:56, Chao Xu <ok...@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 <gk...@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 ?
Re: Crash - looks like 1765 -
Posted by "xuchao@Gmail" <xu...@gmail.com>.
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 <gk...@gmail.com> 写道：
>
>
>
>> On 2018/05/22 08:56:56, Chao Xu <ok...@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 <gk...@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 ?
Re: Crash - looks like 1765 -
Posted by gk...@gmail.com,
gk...@gmail.com.
On 2018/05/22 08:56:56, Chao Xu <ok...@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 <gk...@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 ?
Re: Crash - looks like 1765 -
Posted by Chao Xu <ok...@apache.org>.
Hi salil,
please try to apply
https://github.com/apache/trafficserver/commit/49c903b0c13a2fd2c085325f6942326c4f9c926a
.
- Oknet
2018-05-14 22:03 GMT+08:00 salil GK <gk...@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
Re: Crash - looks like 1765 -
Posted by Chao Xu <ok...@apache.org>.
Hi salil,
please try to apply
https://github.com/apache/trafficserver/commit/49c903b0c13a2fd2c085325f6942326c4f9c926a
.
- Oknet
2018-05-14 22:03 GMT+08:00 salil GK <gk...@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