[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
]
Leif Hedstrom updated TS-1917:
--
Fix Version/s: (was: 6.0.0)
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: Alan M. Carroll
Labels: review
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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
[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
]
Alan M. Carroll updated TS-1917:
Fix Version/s: (was: 5.1.0)
6.0.0
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: 6.0.0
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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
[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
]
Leif Hedstrom updated TS-1917:
--
Fix Version/s: (was: 5.0.0)
5.1.0
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.1.0
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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
[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
]
Leif Hedstrom updated TS-1917:
--
Labels: review (was: )
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 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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
[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
]
Leif Hedstrom updated TS-1917:
--
Fix Version/s: (was: 3.3.6)
3.5.0
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
Fix For: 3.5.0
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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
[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
]
Leif Hedstrom updated TS-1917:
--
Fix Version/s: (was: 3.3.5)
3.3.6
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
Fix For: 3.3.6
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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
[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 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal (this=0x2b34b12070b0)
at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0, event=100,
data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100, vc=0x2b35ff9ef4c0)
at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0, vc=0x2b35ff9ef4c0,
thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io (this=0x2b35ff9ef4c0,
nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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`,
[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:
-
Attachment: 0001-Fix-assert-in-HttpTransact-handle_content_length_hea.patch
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
Attachments:
0001-Fix-assert-in-HttpTransact-handle_content_length_hea.patch
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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
[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:
-
Attachment: (was:
0001-Fix-assert-in-HttpTransact-handle_content_length_hea.patch)
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 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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 !=
[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
]
weijin updated TS-1917:
---
Attachment: ts-1917.wj.diff
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
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 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 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f 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 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd 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,
