You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Susan Hinrichs (JIRA)" <ji...@apache.org> on 2015/10/06 21:32:32 UTC

[jira] [Resolved] (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 resolved TS-3957.
--------------------------------
    Resolution: Fixed

> 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  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)