apache
assert on POST when the data is bigger than the used buffer.
I'm POST'ing a ~320k file and getting the following assert: https://github.com/apache/trafficserver/blob/7543f7d800ae0884245776415400c21de1a6d8b6/proxy/http3/Http3Frame.cc#L455-L458
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff7127859 in __GI_abort () at abort.c:79
#2 0x00007ffff7ef0ff1 in ink_abort (message_format=0x7ffff7f5e020 "%s:%d: failed assertion `%s`") at ink_error.cc:99
#3 0x00007ffff7eebe9d in _ink_assert (expression=0x55555609bded "sizeof(buf) > frame_len", file=0x55555609bccc "Http3Frame.cc", line=458) at ink_assert.cc:37
#4 0x0000555555f84efc in Http3FrameFactory::fast_create (this=0x7fffc821c4f0, reader=..., frame_len=325815) at Http3Frame.cc:458
#5 0x0000555555f8af03 in Http3FrameDispatcher::on_read_ready (this=0x7fffc821c4d0, stream_id=0, reader=..., nread=@0x7fffe7af8cf8: 74) at Http3FrameDispatcher.cc:93
#6 0x0000555555f80682 in Http3Transaction::_process_read_vio (this=0x7fffc821c270) at Http3Transaction.cc:566
#7 0x0000555555f7d5a4 in HQTransaction::do_io_read (this=0x7fffc821c270, c=0x7fffc83c4b20, nbytes=0, buf=0x7fffc821c320) at Http3Transaction.cc:127
#8 0x0000555555b1eecc in HttpSM::attach_client_session (this=0x7fffc83c4b20, client_vc=0x7fffc821c270) at HttpSM.cc:597
#9 0x0000555555e39c43 in ProxyTransaction::new_transaction (this=0x7fffc821c270, from_early_data=false) at ProxyTransaction.cc:63
#10 0x0000555555f75a67 in Http3App::_handle_bidi_stream_on_read_ready (this=0x7fffc81d4400, event=100, vio=0x7fffc81d7580) at Http3App.cc:242
#11 0x0000555555f74ecc in Http3App::main_event_handler (this=0x7fffc81d4400, event=100, data=0x5555565d7800) at Http3App.cc:134
#12 0x0000555555a45497 in Continuation::handleEvent (this=0x7fffc81d4400, event=100, data=0x5555565d7800)
at /home/dmeden/code/git/trafficserver-h3/iocore/eventsystem/I_Continuation.h:228
#13 0x0000555555fbacf7 in EThread::process_event (this=0x555556f7a1f0, e=0x5555565d7800, calling_code=100) at UnixEThread.cc:149
#14 0x0000555555fbaf44 in EThread::process_queue (this=0x555556f7a1f0, NegativeQueue=0x7fffe7af90f0, ev_count=0x7fffe7af90a4, nq_count=0x7fffe7af90a0)
at UnixEThread.cc:184
#15 0x0000555555fbb260 in EThread::execute_regular (this=0x555556f7a1f0) at UnixEThread.cc:241
#16 0x0000555555fbb67e in EThread::execute (this=0x555556f7a1f0) at UnixEThread.cc:334
#17 0x0000555555fb9dc6 in spawn_thread_internal (a=0x5555565ca780) at Thread.cc:79
#18 0x00007ffff7780609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#19 0x00007ffff7224133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) f 4
#4 0x0000555555f84efc in Http3FrameFactory::fast_create (this=0x7fffc821c4f0, reader=..., frame_len=325815) at Http3Frame.cc:458
458 ink_assert(sizeof(buf) > frame_len);
(gdb) print frame_len
$1 = 325815
(gdb) print sizeof(buf)
$2 = 65536
(gdb)
Seems that we could use ats_unique_buf but then we may need to make sure someone owns this.
We probably want to pass the IOBufferReader instead of the buf, and keep data in IOBufferReader to avoid copy (or do less copy).
We probably want to pass the IOBufferReader instead of the
buf, and keep data in IOBufferReader to avoid copy (or do less copy).
and change all the Http3FrameFactory calls(the ones involved) to actually take the IOBufferReader right?
Yes, I'm still not sure how we should handle giga byte size frame, but obviously we can not (and should not) allocate such a big buffer.