Core dump revisited

Nick Craig-Wood nick at craig-wood.com
Tue Dec 19 05:30:05 EST 2006


Sheldon <shejo284 at gmail.com> wrote:
>  Sheldon skrev:
> > Wonderful! Now I know how to used gdb with python.

Good!

> > The are results area posted below. Since I am new at this I could
> > used some help in interpreting the problem. What I do know is
> > this: my allocation of the array is good but when freeing the
> > array, a problem arises. The problem is given below but since I am
> > new as well to C

Ambitious!

> > I sure could use some help.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1077321856 (LWP 32710)]
> > 0x40297b83 in mallopt () from /lib/tls/libc.so.6
> > (gdb) bt
> > #0  0x40297b83 in mallopt () from /lib/tls/libc.so.6
> > #1  0x402958ba in free () from /lib/tls/libc.so.6
> > #2  0x405e070a in MemoryFreeOrd () at msgppsmodule_area.c:1675
> > #3  0x405dae0a in msgppsarea (self=0x0, args=0x4042aa7c, kwargs=0x0) at
> > msgppsmodule_area.c:328
> > #4  0x40073b16 in PyCFunction_Call () from /usr/lib/libpython2.3.so.1.0

Typing "up" and "down" to move up and down the call stack is a good
thing.  Type "l" to see a list of code at the point that things went
wrong.

You can type "print <variablename>" to see the values of variables.
gdb understands most C syntax so you can use "print
this->member[1].data" etc.

This all assumes you compiled and linked with debugging (-g flag to
compiler and linker).  Turning off optimisation may make the debugger
more accurate also.

I can't tell exactly where your program crashed because of line
wrapping it your post, but is it certainly within MemoryFreeOrd().

What I would do next is run the program under gdb, wait for it to
crash then print the values of things in the MemoryFreeOrd() function.
You'll find one of the pointers has been corrupted, ie doesn't point
to valid memory or memory allocated with malloc() I expect.  0 or NULL
is an acceptable input to most free() implementations but not all.

Finding out exactly where that pointer got corrupted is harder.  Maybe
it was never initialised, or maybe you initialised it with a PyObject
or maybe you have a memory scribble somewhere.

A memory scribble is the hardest bug to find because it happened
elsewhere in your program.  Look at the data that was overwritten.
Maybe it is a string you can identify...  You'll also want to start
reading the gdb manual on breakpoints and watchpoints at this moment!

Find memory corruptions can be tricky and time consuming.

Valgrind can help also.

Good luck!
-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick



More information about the Python-list mailing list