[
https://issues.apache.org/jira/browse/TS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190314#comment-14190314
]
Alan M. Carroll commented on TS-3151:
-------------------------------------
Instead of {{get_lock}} it should be {{get_mutex}}. Given the use of the work
"lock" in a different context everywhere nearby, the former could easily be
mistaken.
> 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)
