Core dump revisited

[Sheldon]

Nick Craig-Wood skrev:

> 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


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