[ https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14001919#comment-14001919 ]
Bryan Call commented on TS-1917: -------------------------------- [~jpe...@apache.org] Any updates on this? > It seems that one of assert in HttpTransact::handle_content_length_header() > is unnecessary > ------------------------------------------------------------------------------------------- > > Key: TS-1917 > URL: https://issues.apache.org/jira/browse/TS-1917 > Project: Traffic Server > Issue Type: Bug > Components: HTTP > Reporter: Yunkai Zhang > Assignee: James Peach > Labels: review > Fix For: 5.0.0 > > Attachments: ts-1917.wj.diff > > > ATS crashed by the following assert in debug mode: > {code} > (gdb) bt > #0 0x0000003e86c32885 in raise () from /lib64/libc.so.6 > #1 0x0000003e86c34065 in abort () from /lib64/libc.so.6 > #2 0x00002b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43 > #3 0x00002b349592e301 in ink_fatal_va(int, const char *, typedef > __va_list_tag __va_list_tag *) (return_code=1, > message_format=0x2b349594a748 "%s:%d: failed assert `%s`", > ap=0x2b34979073a0) at ink_error.cc:65 > #4 0x00002b349592e3ca in ink_fatal (return_code=1, > message_format=0x2b349594a748 "%s:%d: failed assert `%s`") at ink_error.cc:73 > #5 0x00002b349592d2cc in _ink_assert (expression=0x70fef0 "s->range_setup != > RANGE_NOT_TRANSFORM_REQUESTED", file=0x70a613 "HttpTransact.cc", line=6660) > at ink_assert.cc:37 > #6 0x000000000059cb57 in HttpTransact::handle_content_length_header > (s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at > HttpTransact.cc:6660 > #7 0x00000000005a116f in HttpTransact::build_response (s=0x2b34b1207120, > base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800, > outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709 > "OK") at HttpTransact.cc:7731 > #8 0x0000000000594972 in > HttpTransact::handle_cache_operation_on_forward_server_response > (s=0x2b34b1207120) at HttpTransact.cc:4373 > #9 0x00000000005924f8 in HttpTransact::handle_forward_server_connection_open > (s=0x2b34b1207120) at HttpTransact.cc:3818 > #10 0x0000000000590c08 in HttpTransact::handle_response_from_server > (s=0x2b34b1207120) at HttpTransact.cc:3495 > #11 0x000000000058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at > HttpTransact.cc:3185 > #12 0x0000000000575f25 in HttpSM::call_transact_and_set_next_state > (this=0x2b34b12070b0, f=0) at HttpSM.cc:6685 > #13 0x0000000000563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at > HttpSM.cc:1555 > #14 0x0000000000563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0, > event=0, data=0x0) at HttpSM.cc:1487 > #15 0x000000000056f79b in HttpSM::do_api_callout_internal > (this=0x2b34b12070b0) at HttpSM.cc:4702 > #16 0x000000000057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at > HttpSM.cc:503 > #17 0x0000000000564b68 in HttpSM::state_read_server_response_header > (this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869 > #18 0x0000000000567140 in HttpSM::main_handler (this=0x2b34b12070b0, > event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501 > #19 0x00000000004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0, > event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146 > #20 0x00000000006ba540 in read_signal_and_update (event=100, > vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138 > #21 0x00000000006bae90 in read_from_net (nh=0x2b34960fdbc0, > vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320 > #22 0x00000000006bcc7f in UnixNetVConnection::net_read_io > (this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at > UnixNetVConnection.cc:818 > #23 0x00000000006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0, > event=5, e=0x2b349cf16b40) at UnixNet.cc:377 > #24 0x00000000004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0, > event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146 > #25 0x00000000006dbcd0 in EThread::process_event (this=0x2b34960fa010, > e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141 > #26 0x00000000006dc2b2 in EThread::execute (this=0x2b34960fa010) at > UnixEThread.cc:265 > #27 0x00000000006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88 > #28 0x0000003e878077f1 in start_thread () from /lib64/libpthread.so.0 > #29 0x0000003e86ce5ccd in clone () from /lib64/libc.so.6 > {code} > By analyzing the code, it seems that this assertion is unnecessary: > When client sends a request to ATS, and the content hits in cache, but if the > cache is STALE, ATS will sent a request to Original-Server. > In this case, the t_sate.source will be updated to > SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in > HttpTransact::handle_cache_operation_on_forward_server_response() > => s->state_machine->do_range_setup_if_necessary(), the s->range_setup could > be updated to RANGE_NOT_TRANSFORM_REQUESTED, > so it might violate the ink_assert(s->range_setup != > RANGE_NOT_TRANSFORM_REQUESTED). > But, I'm not very sure:), hope someone who familiar with this code can give > us some adivise. -- This message was sent by Atlassian JIRA (v6.2#6252)