Blocker Description
We're seeing this crash, particularly (maybe even only) when we reload configurations on a running system:
#0 0x00002aaaaac8d08d in HttpSM::state_cache_open_write (this=0x2ae4964b4600, event=1109, data=0x2ae993968000) at HttpSM.cc:2503 #1 0x00002aaaaac9da9d in HttpSM::main_handler (this=0x2ae4964b4600, event=1109, data=0x2ae993968000) at HttpSM.cc:2661 #2 0x00002aaaaae8c650 in Continuation::handleEvent (data=0x2ae993968000, event=1109, this=<optimized out>) at I_Continuation.h:153 #3 EThread::process_event (this=0x2aaab3208000, e=0x2ae993968000, calling_code=1109) at UnixEThread.cc:148 #4 0x00002aaaaae8d47b in EThread::execute (this=0x2aaab3208000) at UnixEThread.cc:202 #5 0x00002aaaaae8c026 in spawn_thread_internal (a=0x2aaab0b25dc0) at Thread.cc:86 #6 0x00002aaaad6b3aa1 in start_thread (arg=0x2aaab480f700) at pthread_create.c:301 #7 0x00002aaaae8bc93d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
Discussed with amc about what this could be, looking at the code, it seems related to the "new" option proxy.config.http.cache.open_write_fail_action. We've started turning off this setting for now.
The root cause of the crash is
(gdb) p cache_sm.cache_read_vc $1 = (CacheVConnection *) 0x0
I.e. we end up in the CACHE_EVENT_OPEN_READ case, falling through from CACHE_EVENT_OPEN_WRITE_FAILED (which is the value of event):
(gdb) p event $2 = 1109