[
https://issues.apache.org/jira/browse/TS-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15353507#comment-15353507
]
Bryan Call edited comment on TS-4542 at 6/28/16 6:39 PM:
---------------------------------------------------------
This happens when http/1 calls Http2Stream::do_io_close() and the body bytes
have been sent, but not the END_STREAM flag.
In Http2Stream::do_io_close() it calls Http2Stream::send_data_frames() to send
the ending data frame (0 payload and END_STREAM flag), but the current
implementation of Http2Stream::send_data_frames() doesn't send a frame when the
window has been used, even though you can based on the HTTP/2 RFC.
do_io_close() assumes everything has been sent and partially closes the stream
in a half closed state. When another event happens (window update) and we try
to resume sending on the stream, ATS dereferences the parent (a NULL pointer)
and ATS crashes.
This would happen *a lot* more if the usage of ATS is not caching very much. I
am seeing this a couple times a day on a server has a very high cache hit rate.
I had to use the other stream, in the link, parent since it was set to NULL in
the current stream.
{code}
(gdb) p (*(Http2ConnectionState*)this->link.next->parent).client_rwnd
$28 = 0
(gdb) p write_vio.nbytes
$29 = 1041
(gdb) p this->write_vio.ndone
$30 = 1041
(gdb) p body_done
$31 = true
{code}
was (Author: bcall):
This happens when http/1 calls Http2Stream::do_io_close() and the body bytes
have been sent, but not the END_STREAM flag.
In Http2Stream::do_io_close() it calls Http2Stream::send_data_frames() to send
the ending data frame (0 payload and END_STREAM flag), but the current
implementation of Http2Stream::send_data_frames() doesn't send a frame when the
window has been used, even though you can based on the HTTP/2 RFC.
do_io_close() assumes everything has been sent and partially closes the stream
in a half closed state. When another event happens (window update) and we try
to resume sending on the stream, ATS dereferences a parent (a NULL pointer) and
ATS crashes.
This would happen *a lot* more if the usage of ATS is not caching very much. I
am seeing this a couple times a day on a server has a very high cache hit rate.
I had to use the other stream, in the link, parent since it was set to NULL in
the current stream.
{code}
(gdb) p (*(Http2ConnectionState*)this->link.next->parent).client_rwnd
$28 = 0
(gdb) p write_vio.nbytes
$29 = 1041
(gdb) p this->write_vio.ndone
$30 = 1041
(gdb) p body_done
$31 = true
{code}
> ASAN error with HTTP/2 priority
> -------------------------------
>
> Key: TS-4542
> URL: https://issues.apache.org/jira/browse/TS-4542
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
> Affects Versions: 6.2.0
> Reporter: Bryan Call
> Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==29132==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000250 (pc
> 0x0000009a1be5 sp 0x2ae2c2ab0290 bp 0x2ae2c2ab0370 T20)
> #0 0x9a1be4 in Ptr<ProxyMutex>::operator ProxyMutex*() const
> ../../../trafficserver/lib/ts/Ptr.h:317
> #1 0x9a1be4 in Http2ConnectionState::schedule_stream(Http2Stream*)
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:974
> #2 0x99eb7f in Http2ConnectionState::restart_streams()
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:914
> #3 0x99eb7f in rcv_window_update_frame
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:627
> #4 0x9b27c4 in Http2ConnectionState::main_event_handler(int, void*)
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:823
> #5 0x9906e3 in Continuation::handleEvent(int, void*)
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0x9906e3 in send_connection_event
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:58
> #7 0x991145 in Http2ClientSession::state_complete_frame_read(int, void*)
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:430
> #8 0x992ba0 in Continuation::handleEvent(int, void*)
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #9 0x992ba0 in Http2ClientSession::state_start_frame_read(int, void*)
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:403
> #10 0xe2be16 in Continuation::handleEvent(int, void*)
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #11 0xe2be16 in read_signal_and_update
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:153
> #12 0xe2be16 in UnixNetVConnection::readSignalAndUpdate(int)
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:1036
> #13 0xdc791e in SSLNetVConnection::net_read_io(NetHandler*, EThread*)
> ../../../trafficserver/iocore/net/SSLNetVConnection.cc:595
> #14 0xde7db0 in NetHandler::mainNetEvent(int, Event*)
> ../../../trafficserver/iocore/net/UnixNet.cc:513
> #15 0xea2ce9 in Continuation::handleEvent(int, void*)
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #16 0xea2ce9 in EThread::process_event(Event*, int)
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #17 0xea2ce9 in EThread::execute()
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #18 0xe9e128 in spawn_thread_internal
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #19 0x2ae2b8e85aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #20 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
