Susan Hinrichs created TS-3957:
----------------------------------
Summary: 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
We see this in production on machines under swap, so the timings are very
distorted.
{code}
gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x000000000064a5dc in SpdyClientSession::state_session_start
(this=0x2b234fbe8030)
at SpdyClientSession.cc:211
#2 0x0000000000510e34 in Continuation::handleEvent (this=0x2b234fbe8030,
event=1,
data=0x2b23eda76630) at ../iocore/eventsystem/I_Continuation.h:145
#3 0x000000000079a066 in EThread::process_event (this=0x2b21170a2010,
e=0x2b23eda76630,
calling_code=1) at UnixEThread.cc:128
#4 0x000000000079a234 in EThread::execute (this=0x2b21170a2010) at
UnixEThread.cc:179
#5 0x0000000000799611 in spawn_thread_internal (a=0x12226a0) at Thread.cc:85
#6 0x00002b21153e19d1 in start_thread () from /lib64/libpthread.so.0
#7 0x0000003827ee88fd 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)
