Crash in `FreeHook::hook` called from `fork`

[KowalskiThomas]

Found this issue through our Crash Tracking logs in Python apps.

I unfortunately don't have much more context to provide, but I figured I'd create an issue at least to keep track of this, start any discussions and potential investigations, and not forget anything over time.

Error UnixSignal: Process terminated with SI_TKILL (SIGABRT)
#0   0x0000f4a3b36ca83c gsignal
#1   0x0000f4a3b36b7134 abort
#2   0x0000f4a3b3720ba4 cfree
#3   0x0000f4a3b353529c ddprof::(anonymous namespace)::FreeHook::hook
#4   0x0000f4a3b3749d3c fork
#5   0x0000c964894c2ab8 os_fork_impl (/usr/src/python/./Modules/posixmodule.c:7757:11)
#6   0x0000c964894c2ab8 os_fork (/usr/src/python/./Modules/clinic/posixmodule.c.h:4016:12)
#7   0x0000c9648950d898 cfunction_vectorcall_NOARGS (/usr/src/python/Objects/methodobject.c:481:24)
#8   0x0000c964894fb44c _PyObject_VectorcallTstate (/usr/src/python/./Include/internal/pycore_call.h:92:11)
#9   0x0000c964894fb44c PyObject_Vectorcall (/usr/src/python/Objects/call.c:325:12)
#10  0x0000c9648952b480 _PyEval_EvalFrameDefault (/usr/src/python/Python/bytecodes.c:2715:19)
#11  0x0000c964895e8020 PyEval_EvalCode (/usr/src/python/Python/ceval.c:578:21)
#12  0x0000c964896104ac run_eval_code_obj (/usr/src/python/Python/pythonrun.c:1722:9)
#13  0x0000c964896103e8 run_mod (/usr/src/python/Python/pythonrun.c:1743:19)
#14  0x0000c9648960fcbc pyrun_file (/usr/src/python/Python/pythonrun.c:1643:15)
#15  0x0000c9648960f818 _PyRun_SimpleFileObject (/usr/src/python/Python/pythonrun.c:433:13)
#16  0x0000c9648960f5d0 _PyRun_AnyFileObject (/usr/src/python/Python/pythonrun.c:78:15)
#17  0x0000c9648961edb4 pymain_run_file_obj (/usr/src/python/Modules/main.c:360:15)
#18  0x0000c9648961edb4 pymain_run_file (/usr/src/python/Modules/main.c:379:15)
#19  0x0000c9648961edb4 pymain_run_python (/usr/src/python/Modules/main.c:633:21)
#20  0x0000c9648961edb4 Py_RunMain (/usr/src/python/Modules/main.c:713:5)
#21  0x0000c9648961e94c Py_BytesMain (/usr/src/python/Modules/main.c:767:12)
#22  0x0000f4a3b36b74d8 __libc_start_main
#23  0x0000c9648955ab30 _start

[r1viollet]

Do you think ddprof is causing the issue ?

[KowalskiThomas]

As discussed on Slack: I thought I'd report although I'm not positive ddprof is the root cause, mostly because I don't see what else can be.

The crashing service is running ddprof along with ddtrace Python so it could also be a memory corruption from ddtrace (and not a "visible"/obvious ddtrace bug because we don't have a ddtrace frame on the stack).

Ideally to confirm either theory, we'd need to either disable ddtrace on the service (tough sell) or ddprof (easier sell, but somewhat labor intensive in changes and deployments).

Since the crash volume is somewhat low we can also keep that issue open until we get more signal one way or another.