[jira] [Commented] (TS-3151) Segfault on background fill
[ https://issues.apache.org/jira/browse/TS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190373#comment-14190373 ] Acácio Centeno commented on TS-3151: Oh, yes, sorry! the correct would be server_session->get_netvc(). > 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 0x0060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750, > event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171 > #1 0x00652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48, > event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294 > #2 0x006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48, > event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525 > #3 0x004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48, > event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146 > #4 0x0076b140 in write_signal_and_update (event=104, > vc=0x2aab6c003560) at UnixNetVConnection.cc:153 > #5 0x0076b23e in write_signal_done (event=104, nh=0x2f4e2ba0, > vc=0x2aab6c003560) at UnixNetVConnection.cc:180 > #6 0x0076c047 in write_to_net_io (nh=0x2f4e2ba0, > vc=0x2aab6c003560, thread=0x2f4df010) at UnixNetVConnection.cc:471 > #7 0x0076ba17 in write_to_net (nh=0x2f4e2ba0, vc=0x2aab6c003560, > thread=0x2f4df010) at UnixNetVConnection.cc:352 > #8 0x00765216 in NetHandler::mainNetEvent (this=0x2f4e2ba0, > event=5, long double=0x1f87bd0) at UnixNet.cc:415 > #9 0x004ebc5e in Continuation::handleEvent (this=0x2f4e2ba0, > event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146 > #10 0x0078beea in EThread::process_event (this=0x2f4df010, long > double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145 > #11 0x0078c3f4 in EThread::execute (this=0x2f4df010) at > UnixEThread.cc:269 > #12 0x0078b448 in spawn_thread_internal (signed char=0x1f48c20) at > Thread.cc:88 > #13 0x2c97a9d1 in start_thread () from /lib64/libpthread.so.0 > #14 0x2d61c86d 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)
[jira] [Commented] (TS-3151) Segfault on background fill
[ 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 0x0060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750, > event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171 > #1 0x00652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48, > event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294 > #2 0x006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48, > event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525 > #3 0x004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48, > event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146 > #4 0x0076b140 in write_signal_and_update (event=104, > vc=0x2aab6c003560) at UnixNetVConnection.cc:153 > #5 0x0076b23e in write_signal_done (event=104, nh=0x2f4e2ba0, > vc=0x2aab6c003560) at UnixNetVConnection.cc:180 > #6 0x0076c047 in write_to_net_io (nh=0x2f4e2ba0, > vc=0x2aab6c003560, thread=0x2f4df010) at UnixNetVConnection.cc:471 > #7 0x0076ba17 in write_to_net (nh=0x2f4e2ba0, vc=0x2aab6c003560, > thread=0x2f4df010) at UnixNetVConnection.cc:352 > #8 0x00765216 in NetHandler::mainNetEvent (this=0x2f4e2ba0, > event=5, long double=0x1f87bd0) at UnixNet.cc:415 > #9 0x004ebc5e in Continuation::handleEvent (this=0x2f4e2ba0, > event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146 > #10 0x0078beea in EThread::process_event (this=0x2f4df010, long > double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145 > #11 0x0078c3f4 in EThread::execute (this=0x2f4df010) at > UnixEThread.cc:269 > #12 0x0078b448 in spawn_thread_internal (signed char=0x1f48c20) at > Thread.cc:88 > #13 0x2c97a9d1 in start_thread () from /lib64/libpthread.so.0 > #14 0x2d61c86d 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)
[jira] [Commented] (TS-3151) Segfault on background fill
[ https://issues.apache.org/jira/browse/TS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190215#comment-14190215 ] Alan M. Carroll commented on TS-3151: - I tried the patch but it doesn't compile - {code} server_entry && server_entry->vc && server_entry->vc->server_vc {code} {{server_entry->vc}} is a {{VConnection}} which doesn't have an exposed member {{server_vc}}. The line of the crash uses {{server_session->get_netvc()}} with the assertion that {{server_entry->vc == server_session}}. Based on the logic I will presume the additional check in {{is_bg_fill_necessary}} is for {{server_session->get_netvc()}} which seems reasonable, as the point is to check that we have a valid origin server source. > 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 0x0060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750, > event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171 > #1 0x00652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48, > event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294 > #2 0x006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48, > event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525 > #3 0x004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48, > event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146 > #4 0x0076b140 in write_signal_and_update (event=104, > vc=0x2aab6c003560) at UnixNetVConnection.cc:153 > #5 0x0076b23e in write_signal_done (event=104, nh=0x2f4e2ba0, > vc=0x2aab6c003560) at UnixNetVConnection.cc:180 > #6 0x0076c047 in write_to_net_io (nh=0x2f4e2ba0, > vc=0x2aab6c003560, thread=0x2f4df010) at UnixNetVConnection.cc:471 > #7 0x0076ba17 in write_to_net (nh=0x2f4e2ba0, vc=0x2aab6c003560, > thread=0x2f4df010) at UnixNetVConnection.cc:352 > #8 0x00765216 in NetHandler::mainNetEvent (this=0x2f4e2ba0, > event=5, long double=0x1f87bd0) at UnixNet.cc:415 > #9 0x004ebc5e in Continuation::handleEvent (this=0x2f4e2ba0, > event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146 > #10 0x0078beea in EThread::process_event (this=0x2f4df010, long > double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145 > #11 0x0078c3f4 in EThread::execute (this=0x2f4df010) at > UnixEThread.cc:269 > #12 0x0078b448 in spawn_thread_internal (signed char=0x1f48c20) at > Thread.cc:88 > #13 0x2c97a9d1 in start_thread () from /lib64/libpthread.so.0 > #14 0x2d61c86d 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)