ATS9: Crash in HttpSessionAccept

[shinrich]

Testing our latest sync with the 9.0.x branch. Got this stack 3 times in 30 minutes.

The value of new_session->accept_options appears to be bogus. It should be the same value as the this pointer. Presumably it got overwritten in the call to new_connection. Actually the entire new_session object looks bogus.

{code}
(gdb) bt
#0 0x000000000051248c in HttpSessionAccept::accept(NetVConnection*, MIOBuffer*, IOBufferReader*) () at ../../../../../../_vcs/trafficserver9/proxy/http/HttpSessionAccept.cc:59
#1 0x00000000006b1f98 in ProtocolProbeTrampoline::ioCompletionEvent (this=0x2b4516402e20, event=, edata=)
at ../../../../../_vcs/trafficserver9/proxy/ProtocolProbeSessionAccept.cc:147
#2 0x00000000006f5c95 in handleEvent (data=0x2b46a1f469c8, event=100, this=0x2b4516402e20)
at /sd/workspace/src/git.ouroath.com/Edge/build/_build/build_release_posix-x86_64_gcc_8/trafficserver9/build/../../../../_vcs/trafficserver9/iocore/eventsystem/I_Continuation.h:167
#3 handleEvent (data=0x2b46a1f469c8, event=100, this=0x2b4516402e20)
at /sd/workspace/src/git.ouroath.com/Edge/build/_build/build_release_posix-x86_64_gcc_8/trafficserver9/build/../../../../_vcs/trafficserver9/iocore/eventsystem/I_Continuation.h:163
#4 read_signal_and_update (vc=vc@entry=0x2b46a1f46800, event=event@entry=100) at ../../../../../../_vcs/trafficserver9/iocore/net/UnixNetVConnection.cc:83
#5 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2b46a1f46800, event=event@entry=100) at ../../../../../../_vcs/trafficserver9/iocore/net/UnixNetVConnection.cc:1006
#6 0x00000000006d36e4 in SSLNetVConnection::net_read_io(NetHandler*, EThread*) () at ../../../../../../_vcs/trafficserver9/iocore/net/SSLNetVConnection.cc:638
#7 0x00000000006ea14d in NetHandler::process_ready_list (this=this@entry=0x2b451239e430) at ../../../../../../_vcs/trafficserver9/iocore/net/UnixNet.cc:401
#8 0x00000000006ea52f in NetHandler::waitForActivity(long) () at ../../../../../../_vcs/trafficserver9/iocore/net/UnixNet.cc:534
#9 0x0000000000738063 in EThread::execute_regular (this=this@entry=0x2b451239a700) at ../../../../../../_vcs/trafficserver9/iocore/eventsystem/UnixEThread.cc:274
#10 0x00000000007382c6 in execute (this=0x2b451239a700) at ../../../../../../_vcs/trafficserver9/iocore/eventsystem/UnixEThread.cc:338
#11 EThread::execute (this=0x2b451239a700) at ../../../../../../_vcs/trafficserver9/iocore/eventsystem/UnixEThread.cc:316
#12 0x0000000000736589 in spawn_thread_internal (a=0x2b4510cda200) at ../../../../../../_vcs/trafficserver9/iocore/eventsystem/Thread.cc:92
#13 0x00002b450f129dd5 in start_thread () from /lib64/libpthread.so.0
#14 0x00002b450fe5eead in clone () from /lib64/libc.so.6
(gdb) print this
$1 = (HttpSessionAccept * const) 0x2b4683720da0
(gdb) print new_session->accept_options
$2 = (const HttpSessionAccept::Options *) 0x4552423325423325
(gdb) print new_session->accept_options
{code}

[shinrich]

Looking back through our core history, we last saw this problem in Dec 2019. Unfortunately, I cannot find which specific fixes addressed this issue. But there were lots of fixes coming in around that time.