Objgraph segfaults when printing data about leaking C objects
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 840
- Forks
- 72
- PR merge metrics
- No merged PRs in 30d
Description
traceback from gdb: (show_most_common_types was called)
```c
Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007ffff7b5949f in PyObject_Malloc () from /usr/lib/libpython3.7m.so.1.0
(gdb) bt
#0 0x00007ffff7b5949f in PyObject_Malloc () from /usr/lib/libpython3.7m.so.1.0
#1 0x00007ffff7b80ba5 in _PyLong_New () from /usr/lib/libpython3.7m.so.1.0
#2 0x00007ffff7b8132b in PyLong_FromLong () from /usr/lib/libpython3.7m.so.1.0
#3 0x00007ffff7b6d88d in PyNumber_Add () from /usr/lib/libpython3.7m.so.1.0
#4 0x00007ffff7bf365e in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#5 0x00007ffff7ba1d18 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.7m.so.1.0
#6 0x00007ffff7ba2da3 in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#7 0x00007ffff7bb5c30 in ?? () from /usr/lib/libpython3.7m.so.1.0
#8 0x00007ffff7bf3b96 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#9 0x00007ffff7ba1d18 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.7m.so.1.0
#10 0x00007ffff7ba2da3 in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#11 0x00007ffff7bb5c30 in ?? () from /usr/lib/libpython3.7m.so.1.0
#12 0x00007ffff7bf3b96 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#13 0x00007ffff7ba1d18 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.7m.so.1.0
#14 0x00007ffff7ba2da3 in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#15 0x00007ffff7bb5c30 in ?? () from /usr/lib/libpython3.7m.so.1.0
#16 0x00007ffff7bf3b96 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#17 0x00007ffff7ba1d18 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.7m.so.1.0
#18 0x00007ffff7ba2aca in PyEval_EvalCodeEx () from /usr/lib/libpython3.7m.so.1.0
#19 0x00007ffff7ba2aec in PyEval_EvalCode () from /usr/lib/libpython3.7m.so.1.0
#20 0x00007ffff7c738a5 in ?? () from /usr/lib/libpython3.7m.so.1.0
#21 0x00007ffff7c73c2b in PyRun_FileExFlags () from /usr/lib/libpython3.7m.so.1.0
#22 0x00007ffff7c79ec7 in PyRun_SimpleFileExFlags () from /usr/lib/libpython3.7m.so.1.0
#23 0x00007ffff7c7c022 in ?? () from /usr/lib/libpython3.7m.so.1.0
#24 0x00007ffff7c7c1cc in _Py_UnixMain () from /usr/lib/libpython3.7m.so.1.0
#25 0x00007ffff7de5ee3 in __libc_start_main () from /usr/lib/libc.so.6
#26 0x000055555555505e in _start ()
```
For context, it seems about 1.7 GB worth of memory is leaking, so it's likely objgraph is unable to keep up with such heaps of data and tries to allocate more than is available.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the crash around show_most_common_types with a heap of roughly 1.7 GB, then inspect the supplied gdb traceback and Python 3.7 allocation frames. Done means identifying and preventing the segfault, or documenting a bounded failure mode when objgraph processes such a large leaking heap.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100