glibc检测到*** free（）：无效的指针：Python c ++和Swig

Question

I have to run some unit tests which are written in Python. We have the code to test in c++, so I compiled it into a shared object and using swig providing an interface for the python scripts to call into the necessary api's to test.

Now when i run one of the python scripts (it is obviously accessing the c++ codebase which i intend to test), i am getting a "glibc detected free(): invalid pointer". Now I do understand that there is some memory issue, either a double free or I am freeing an inaccessible memory. Now what i am requesting from you experts:

1] I am not getting any backtrace(no line number even), is there anyway to know where the issue is happening? I am not getting any info other than the script stopping abruptly at some point and printing something like this
*** glibc detected * free(): invalid pointer: 0x099e9b28 ***
Can i get a backtrace somehow? By setting some flag may be?

2] I ran valgrind:
"valgrind --leak-check=yes ./myscript.py"
I did not get something much, some lines from it:
glibc detected free(): invalid pointer: 0x099e9b28
==25728==
==25728== Conditional jump or move depends on uninitialised value(s)
==25728== at 0x625AEA: PyObject_Free (in /usr/lib/libpython2.3.so.1.0)
==25728== by 0x614C7F: (within /usr/lib/libpython2.3.so.1.0)
==25728== by 0x61EA53: (within /usr/lib/libpython2.3.so.1.0)

I am not getting anything related to my code basically. So is there something else i should do with valgrind.

3] I tried printfs, its taking me to nothing actually.
4] I tried gdb:
prompt>gdb python
gdb> set args myscript.py
gdb> run

This runs the script, I could not set any breakpoints, it runs and prints the error. No absolute help. Is there something else i should do with GDB? Any way to set breakpoints?

Thanks a lot for any kind of pointer you guys can give me.

Answer 1

I finally figured out! I executed the command
ulimit -c unlimited

After this i see a core dump, now i can analyse it via
gdb /usr/bin/python2.3 core.31685

Answer 2

I have successfully debugged this type of problem using Google's heap checker . It will give you the stack traces both of the point of allocation and deallocation.