You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Alan M. Carroll (JIRA)" <ji...@apache.org> on 2014/10/30 18:05:34 UTC

[jira] [Resolved] (TS-3151) Segfault on background fill

     [ https://issues.apache.org/jira/browse/TS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alan M. Carroll resolved TS-3151.
---------------------------------
    Resolution: Fixed

> Segfault on background fill
> ---------------------------
>
>                 Key: TS-3151
>                 URL: https://issues.apache.org/jira/browse/TS-3151
>             Project: Traffic Server
>          Issue Type: Bug
>            Reporter: Acacio Centeno
>            Assignee: Alan M. Carroll
>
> On rare occasions, a background fill will fail and lead to a segfault, with the following stacktrace:
> #0  0x000000000060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750, event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171
> #1  0x0000000000652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48, event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294
> #2  0x00000000006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48, event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525
> #3  0x00000000004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48, event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146
> #4  0x000000000076b140 in write_signal_and_update (event=104, vc=0x2aab6c003560) at UnixNetVConnection.cc:153
> #5  0x000000000076b23e in write_signal_done (event=104, nh=0x2aaaaf4e2ba0, vc=0x2aab6c003560) at UnixNetVConnection.cc:180
> #6  0x000000000076c047 in write_to_net_io (nh=0x2aaaaf4e2ba0, vc=0x2aab6c003560, thread=0x2aaaaf4df010) at UnixNetVConnection.cc:471
> #7  0x000000000076ba17 in write_to_net (nh=0x2aaaaf4e2ba0, vc=0x2aab6c003560, thread=0x2aaaaf4df010) at UnixNetVConnection.cc:352
> #8  0x0000000000765216 in NetHandler::mainNetEvent (this=0x2aaaaf4e2ba0, event=5, long double=0x1f87bd0) at UnixNet.cc:415
> #9  0x00000000004ebc5e in Continuation::handleEvent (this=0x2aaaaf4e2ba0, event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146
> #10 0x000000000078beea in EThread::process_event (this=0x2aaaaf4df010, long double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145
> #11 0x000000000078c3f4 in EThread::execute (this=0x2aaaaf4df010) at UnixEThread.cc:269
> #12 0x000000000078b448 in spawn_thread_internal (signed char=0x1f48c20) at Thread.cc:88
> #13 0x00002aaaac97a9d1 in start_thread () from /lib64/libpthread.so.0
> #14 0x00002aaaad61c86d in clone () from /lib64/libc.so.6
> This seems close to the issue reported on https://issues.apache.org/jira/browse/TS-2705
> Except that in our case, server_entry->vc->server_vc was NULL, so maybe the appropriate solution would be to add that to the check done in is_bg_fill_necessary, like:
>   if (c->producer->alive && // something there to read
>       server_entry && server_entry->vc && server_entry->vc->server_vc && // from an origin server
>       c->producer->num_consumers > 1  // with someone else reading it
>     ) {
> ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)