Nick Craig-Wood skrev: > Sheldon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
Man. You are good. This is most insight I have had from anyone. I did initialize the arrays with PyObjects and today, after hours of debugging and now with your insight, I think the problem lies here: /* here a python list of strings is read into a C string array */ static int readPythonObject(void) { int i; PyObject *msgop; PyObject *ppsop; PyObject *tileop; PyObject *sceneop; for (i = 0; i < work.sumscenes; i++) { msgop = PyList_GetItem(work.msgobj, i); work.msg_scenes[i] = PyString_AsString(msgop); ppsop = PyList_GetItem(work.ppsobj, i); work.pps_scenes[i] = PyString_AsString(ppsop); } for (i = 0; i < NumberOfTiles; i++) { tileop = PyList_GetItem(work.tileobj, i); work.tiles[i] = PyString_AsString(tileop); sceneop = PyList_GetItem(work.nscenesobj, i); work.nscenes[i] = PyInt_AsLong(sceneop); } return 1; } /*end readPythonObject*/ I am new to this and copied this code from a colleague. So, it corrupts the pointer. How do I do this properly? Your help is truly appreciated! /S -- http://mail.python.org/mailman/listinfo/python-list