Pytest-memray segfaults where memray does not #138
Description
Hello, I am currently getting a segfault on a private codebase when using pytest-memray, but I am NOT getting the same segfault when using only memray without the pytest extension to profile python/pytest, i.e. running pytest --memray ... causes a segfault but memray run -m pytest ... does not.
I initially suspected pytest-memray was not activating greenlet support correctly compared to core memray, as we use the async engine in sqlalchemy and other users have reported segfaults without this support: bloomberg/memray#166. However, I have confirmed via logged warnings that greenlet support is active on both pytest-memray and memray core when running pytest for my codebase. Additionally, the stack trace from the coredump looks a bit related to segfaulting when trying to trace a malloc call than tracing a function like in the linked bug:
#0 0x00007f505bc52e2c in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f505bc03fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#2 <signal handler called>
#3_PyCode_LineNumberFromArray (index=151147732, co=0x7f4f94022b20) at /usr/local/src/conda/python-3.11.9/Include/internal/pycore_code.h: 556
#4 PyCode_Addr2Line (co=0x7f4f94022620, addrq-302295464) at /usr/local/src/conda/python-3.11.9/0bjects/codeobject.c:773
#5 0x00007f505a2a274e in memray:: tracking_api:: PythonStackTracker::emitPending PushesAndPops() [clone .constprop.0] (this <optimized out>) at src/memray/_memray/tracking_api.cpp:182
#6 0x00007f505a28f2ad in memray:: tracking_api:: Tracker:: trackAllocationImpl (this=0x55a999bcae10, ptr=0x7f4f94051800, size=528, func=<optimized out>, trace...) at src/memray/_memray/tracking_api.cpp:153
#7 0x00007f505a27b578 in memray:: tracking_api:: Tracker:: trackAllocation (func=memray:: hooks:: Allocator:: MALLOC, size 528, ptr=0x7f4f94051800) at src/memray/_memray/tracking_api.h:228
#8 memray:: intercept::malloc (size=528) at src/memray/_memray/hooks.cpp:177
#9 0x000055a995289924 in PyMem_RawMalloc (size=<optimized out>, ctx=<optimized out>) at /usr/local/src/conda/python-3.11.9/Objects/obmalloc.c:181
#10 PyMem_RawMalloc (size=<optimized out>) at /usr/local/src/conda/python-3.11.9/Objects/obmalloc.c:586
#11_PyObject_Malloc (ctx=<optimized out>, nbytes=<optimized out>) at /usr/local/src/conda/python-3.11.9/Objects/obmalloc.c:2003
#12_PyObject_Malloc (nbytes=528, ctx=<optimized out>) at /usr/local/src/conda/python-3.11.9/Objects/obmalloc.c:1996
#13 PyMem Malloc (size=size@entry=528) at /usr/local/src/conda/python-3.11.9/0bjects/obmalloc.c:623
#14 0x000055a9953a0c78 in newblock (deque deque@entry=0x7f4f9f3cb970) at /usr/local/src/conda/python-3.11.9/Modules/_collectionsmodule.c:132
#15 0x000055a9953a0c0d in deque_new (type=<optimized out, args=<optimized out>, kwds=<optimized out>)
at /usr/local/src/conda/python-3.11.9/Modules/_collectionsmodule.c:162
#16 0x000055a9952997e4 in type_call (kwds=0x0, args=(), type-0x55a9955e7d20 <deque_type>) at /usr/local/src/conda/python-3.11.9/Objects/typeobject.c:1
#17_PyObject_MakeTpCall (tstate=0x55a99b1e0140, callable <type at remote 0x55a9955e7d20>, args=<optimized out>, nargs=0, keywords=0x0) at /usr/local/src/conda/python-3.11.9/Objects/call.c:214
#18 0x000055a9951bd584 in trace_call_function (kwnames-exe, nargs=0, args=<optimized out>, func=<type at remote 0x55a9955e7d20>, tstate=<optimized out: at /usr/local/src/conda/python-3.11.9/Python/ceval.c:7307
#19_PyEval_EvalFrameDefault (tstate-tstate@entry=0x55a99b1e0140, frame=<optimized out>, frame@entry=0x7f5059884890, throwflag-throwflag@entry=0)
at /usr/local/src/conda/python-3.11.9/Python/ceval.c:4764
#20 0x000055a9952ca981 in _PyEval_EvalFrame (throwflag=0, frame=0x7f5059884890, tstate=0x55a99b1e0140)
at /usr/local/src/conda/python-3.11.9/Include/internal/pycore ceval.h:73
Obviously we don't expect a segfault when running memray, but also it's strange that it only happens with pytest-memray and not when using memray core.
Given I've confirmed greenlet is activated in both cases, I'm not sure how to proceed with further debugging the cause of this segfault.