2

We have a rather large and complex Python program which has many SWIG-wrapped C/C++ parts as well.

After attempting to implement a new part of this system, I keep hitting "Fatal Python error: GC object already tracked" and then a segmentation fault.

This occurs with regularity on Linux (64-bit OS/app) and Windows 10 (32-bit OS/app)

I've looked all over the web, have played with gdb backtraces on the coredumps, using Python's own gc module inspection, and sys.settrace(), valgrind, and more and after several days have still not managed to get any closer to working out WHAT the object that is already tracked is.

Why doesn't Python tell us this information?

Is there any way I can try and find out WHAT the object is that's causing this fatal error, so I can correct my code to behave correctly?

Danny S
  • 457
  • 4
  • 15
  • In general the time the error is observed is not necessarily related to what object has the issue. To diagnose these types of errors in the past I've had success building a debug build of python with `--without-pymalloc` for better valgrind reporting and/or building tests that call functions which might be the candidate (and nothing else) in a tight loop 100,000 times in a row from 100 threads. Once you isolate that it's a question of tracking down the root cause by studying the code paths carefully. – Flexo Dec 22 '16 at 02:40

0 Answers0