You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Yunkai Zhang (JIRA)" <ji...@apache.org> on 2013/05/22 11:44:20 UTC
[jira] [Updated] (TS-1917) It seems that one of assert in
HttpTransact::handle_content_length_header() is unnecessary
[ https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yunkai Zhang updated TS-1917:
-----------------------------
Description:
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.
was:
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 the cache is STALE, so ATS will sent a request to Original-Server. In this case, the t_sate.source will be updated to SOURCE_HTTP_ORIGIN_SERVER(original 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.
> 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
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira