[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056583#comment-14056583 ] ASF subversion and git services commented on TS-2780: - Commit 993bf5b23757abe95a657e0eee22c914a0964dbf in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=993bf5b ] updated changes to include TS-2780 > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.1.0 > > Attachments: TS-2780.diff, ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056581#comment-14056581 ] ASF subversion and git services commented on TS-2780: - Commit 59d0e65224860cd906f04ed18aed4951baba05ba in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=59d0e65 ] Revert "TS-2780: Core dump in SpdyRequest::clear() in production testing of SPDY" This reverts commit c9d4433531767c9b5f6db42b488af4552bc5c4a9. > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.1.0 > > Attachments: TS-2780.diff, ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056582#comment-14056582 ] ASF subversion and git services commented on TS-2780: - Commit fbf966eb603e2a202fe91144bd1a098fec628a6e in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fbf966e ] TS-2780: Core dump in SpdyRequest::clear() in production testing of SPDY > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.1.0 > > Attachments: TS-2780.diff, ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056543#comment-14056543 ] Bryan Call commented on TS-2780: >From dev@ {code} Good suggestion - will update and resubmit the patch. Thank you, Sudheer On 7/8/14, 12:38 PM, "James Peach" wrote: A helper function would make this cleaner: SpdyRequest * SpdyClientSession::find_request(int streamid) { map::iterator iter = this->req_map.find(streamid); return iter == this->req_map.end() ? NULL : iter->second; } {code} > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.1.0 > > Attachments: TS-2780.diff, ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055362#comment-14055362 ] ASF subversion and git services commented on TS-2780: - Commit c9d4433531767c9b5f6db42b488af4552bc5c4a9 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c9d4433 ] TS-2780: Core dump in SpdyRequest::clear() in production testing of SPDY > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.1.0 > > Attachments: TS-2780.diff, ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055167#comment-14055167 ] Bryan Call commented on TS-2780: There are a few places in the code where the [] operator is used and can add elements to the map. > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.1.0 > > Attachments: ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055175#comment-14055175 ] Sudheer Vinukonda commented on TS-2780: --- Yes, I just gave an example above. Will fix all the relevant places. > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.1.0 > > Attachments: ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055129#comment-14055129 ] Sudheer Vinukonda commented on TS-2780: --- I am finally able to reproduce this error message and understand the issue. Basically, this happens, due to a race condition, when the client sends a DATA frame while ATS sends an error in SYN_REPLY (e.g. a POST transaction with client trying to send a large data file, but, ATS denies POST transactions from the client using ip_allow ACL). E.g. % spdycat -3 -v https://abc.com -d /tmp/1 > /tmp/2 (where /tmp/1 is a large data file with about 5K lines). The issue happens due to the code in spdy_on_data_chunk_recv_callback(), spdy_on_data_recv_callback() etc. Basically, when the error happens, the request is deleted and erased from client_session->req_map. However, the data frame may still be received after the req object is deleted. The below code correctly ignores the data frames, since, the request has been deleted already - but, the statement "SpdyRequest *req = sm->req_map[stream_id];" results in adding an element with key stream_id to the req_map with value NULL. A correct way to check if the req has been erased from the map is to check if the iterator pointing to that element is valid. Will test and upload a patch shortly .. {code} void spdy_on_data_chunk_recv_callback(spdylay_session * /*session*/, uint8_t /*flags*/, int32_t stream_id, const uint8_t *data, size_t len, void *user_data) { SpdyClientSession *sm = (SpdyClientSession *)user_data; SpdyRequest *req = sm->req_map[stream_id]; // // SpdyRequest has been deleted on error, drop this data; // if (!req) return; {code} > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.1.0 > > Attachments: ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 i
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14005410#comment-14005410 ] Bryan Call commented on TS-2780: On a production host that is serving static content: {code} -bash-4.1$ sudo grep 'req null in SpdSM::clear' diags.log [May 9 03:30:36.579] Server {0x2b64cd55e700} ERROR: req null in SpdSM::clear [May 19 22:13:05.611] Server {0x2ac876fc9700} ERROR: req null in SpdSM::clear [May 21 05:14:47.868] Server {0x2ada465bf700} ERROR: req null in SpdSM::clear [May 21 18:48:41.789] Server {0x2b413be45700} ERROR: req null in SpdSM::clear {code} > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.0.0 > > Attachments: ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990217#comment-13990217 ] Yunkai Zhang commented on TS-2780: -- [~bcall]: I think this issue should be kept unresolved status before finding out the root cause: Why {{req_map}} contains unexpected NULL values? > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.0.0 > > Attachments: ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990135#comment-13990135 ] ASF subversion and git services commented on TS-2780: - Commit 6d15b4e5815932f70c958d10e46beb121e3f1d89 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6d15b4e ] Added TS-2780 to changes > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda > Labels: spdy, yahoo > Fix For: 5.0.0 > > Attachments: ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990134#comment-13990134 ] ASF subversion and git services commented on TS-2780: - Commit 4bae1eef6dd33f8f56c0c15a9848ffcde3b9d577 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4bae1ee ] TS-2780: Core dump in SpdyRequest::clear() in production testing of SPDY > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda > Labels: spdy, yahoo > Fix For: 5.0.0 > > Attachments: ts2780.diff > > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[ https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13989839#comment-13989839 ] Sudheer Vinukonda commented on TS-2780: --- Trying out a simple fix with check for null pointer in SpdyRequest::clear() as below - {code} --- a/proxy/spdy/SpdySM.cc 2014-05-02 17:07:21.759120034 + +++ b/proxy/spdy/SpdySM.cc 2014-05-05 18:48:49.005076559 + @@ -113,8 +113,11 @@ map::iterator endIter = req_map.end(); for(; iter != endIter; ++iter) { SpdyRequest *req = iter->second; -req->clear(); -spdyRequestAllocator.free(req); +if (req) +{ + req->clear(); + spdyRequestAllocator.free(req); +} } req_map.clear(); {code} > Core dump in SpdyRequest::clear() in production testing of SPDY > --- > > Key: TS-2780 > URL: https://issues.apache.org/jira/browse/TS-2780 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda > Labels: SPDY_ATS > > Noticed the below core dump in SpdyRequest::clear() during production testing > on our proxy platform. > {code} > NOTE: Traffic Server received Sig 11: Segmentation fault > /home/y/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500] > /home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4] > /home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84] > /home/y/bin/traffic_server[0x5d13d1] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453] > /home/y/bin/traffic_server[0x713e5a] > /lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851] > /lib64/libc.so.6(clone+0x6d)[0x34202e894d] > {code} > gdb output shows that req may be a null pointer in SpdySM::clear() > {code} > (gdb) bt > #0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44 > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > #2 0x005d13d1 in spdy_default_handler (contp=, > event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=) at > SpdySM.cc:258 > #3 0x006eeabb in handleEvent (event=, > vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146 > #4 read_signal_and_update (event=, vc=0x2aefcc141ca0) > at UnixNetVConnection.cc:216 > #5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0, > event=, e=) at > UnixNetVConnection.cc:1152 > #6 0x006e7d0e in handleEvent (this=0x1634af0, event= out>, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146 > #7 InactivityCop::check_inactivity (this=0x1634af0, event= out>, e=0x136e850) at UnixNet.cc:67 > #8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2) > at UnixEThread.cc:145 > #10 0x00715623 in EThread::execute (this=0x2aef48f91010) at > UnixEThread.cc:224 > #11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88 > #12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0 > #13 0x0034202e894d in clone () from /lib64/libc.so.6 > (gdb) print this > $1 = (SpdyRequest * const) 0x0 > (gdb) up > #1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116 > 116 in SpdySM.cc > (gdb) print req > $2 = (SpdyRequest *) 0x0 > (gdb) print iter > $3 = {first = 25, second = } > (gdb) print req_map > $4 = std::map with 3 elements = { > [1] = 0x2aefd81e5ae0, > [25] = 0x0, > [27] = 0x0 > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)