[jira] [Updated] (TS-3957) core dump from SpdyClientSession::state_session_start
[ https://issues.apache.org/jira/browse/TS-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3957: -- Summary: core dump from SpdyClientSession::state_session_start (was: Core dump from SpdyClientSession::state_session_start) > core dump from SpdyClientSession::state_session_start > - > > Key: TS-3957 > URL: https://issues.apache.org/jira/browse/TS-3957 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Labels: yahoo > Fix For: 6.1.0 > > > We see this in production on machines under swap, so the timings are very > distorted. > {code} > gdb) bt > #0 0x in ?? () > #1 0x0064a5dc in SpdyClientSession::state_session_start > (this=0x2b234fbe8030) > at SpdyClientSession.cc:211 > #2 0x00510e34 in Continuation::handleEvent (this=0x2b234fbe8030, > event=1, > data=0x2b23eda76630) at ../iocore/eventsystem/I_Continuation.h:145 > #3 0x0079a066 in EThread::process_event (this=0x2b21170a2010, > e=0x2b23eda76630, > calling_code=1) at UnixEThread.cc:128 > #4 0x0079a234 in EThread::execute (this=0x2b21170a2010) at > UnixEThread.cc:179 > #5 0x00799611 in spawn_thread_internal (a=0x12226a0) at Thread.cc:85 > #6 0x2b21153e19d1 in start_thread () from /lib64/libpthread.so.0 > #7 0x003827ee88fd in clone () from /lib64/libc.so.6 > {code} > After poking around on the core some more [~amc] and I determined that the vc > referenced by the SpdyClientSession was a freed object (the vtable pointer > was swizzled out to be the freelist next pointer). > We assume that the swapping is causing very odd event timing. We replaced > the schedule_immediate with a direct call that that seemed to solve our crash > in production. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3957) Core dump from SpdyClientSession::state_session_start
[ https://issues.apache.org/jira/browse/TS-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3957: --- Fix Version/s: 6.1.0 > Core dump from SpdyClientSession::state_session_start > - > > Key: TS-3957 > URL: https://issues.apache.org/jira/browse/TS-3957 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Labels: yahoo > Fix For: 6.1.0 > > > We see this in production on machines under swap, so the timings are very > distorted. > {code} > gdb) bt > #0 0x in ?? () > #1 0x0064a5dc in SpdyClientSession::state_session_start > (this=0x2b234fbe8030) > at SpdyClientSession.cc:211 > #2 0x00510e34 in Continuation::handleEvent (this=0x2b234fbe8030, > event=1, > data=0x2b23eda76630) at ../iocore/eventsystem/I_Continuation.h:145 > #3 0x0079a066 in EThread::process_event (this=0x2b21170a2010, > e=0x2b23eda76630, > calling_code=1) at UnixEThread.cc:128 > #4 0x0079a234 in EThread::execute (this=0x2b21170a2010) at > UnixEThread.cc:179 > #5 0x00799611 in spawn_thread_internal (a=0x12226a0) at Thread.cc:85 > #6 0x2b21153e19d1 in start_thread () from /lib64/libpthread.so.0 > #7 0x003827ee88fd in clone () from /lib64/libc.so.6 > {code} > After poking around on the core some more [~amc] and I determined that the vc > referenced by the SpdyClientSession was a freed object (the vtable pointer > was swizzled out to be the freelist next pointer). > We assume that the swapping is causing very odd event timing. We replaced > the schedule_immediate with a direct call that that seemed to solve our crash > in production. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3957) Core dump from SpdyClientSession::state_session_start
[ https://issues.apache.org/jira/browse/TS-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3957: --- Labels: yahoo (was: ) > Core dump from SpdyClientSession::state_session_start > - > > Key: TS-3957 > URL: https://issues.apache.org/jira/browse/TS-3957 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Labels: yahoo > > We see this in production on machines under swap, so the timings are very > distorted. > {code} > gdb) bt > #0 0x in ?? () > #1 0x0064a5dc in SpdyClientSession::state_session_start > (this=0x2b234fbe8030) > at SpdyClientSession.cc:211 > #2 0x00510e34 in Continuation::handleEvent (this=0x2b234fbe8030, > event=1, > data=0x2b23eda76630) at ../iocore/eventsystem/I_Continuation.h:145 > #3 0x0079a066 in EThread::process_event (this=0x2b21170a2010, > e=0x2b23eda76630, > calling_code=1) at UnixEThread.cc:128 > #4 0x0079a234 in EThread::execute (this=0x2b21170a2010) at > UnixEThread.cc:179 > #5 0x00799611 in spawn_thread_internal (a=0x12226a0) at Thread.cc:85 > #6 0x2b21153e19d1 in start_thread () from /lib64/libpthread.so.0 > #7 0x003827ee88fd in clone () from /lib64/libc.so.6 > {code} > After poking around on the core some more [~amc] and I determined that the vc > referenced by the SpdyClientSession was a freed object (the vtable pointer > was swizzled out to be the freelist next pointer). > We assume that the swapping is causing very odd event timing. We replaced > the schedule_immediate with a direct call that that seemed to solve our crash > in production. -- This message was sent by Atlassian JIRA (v6.3.4#6332)