Hi all,
problem finally solved, see bellow.
----- Original Message -----
From: "Tobbi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 11, 2003 11:48 AM
Subject: Re: [pygtk] PyGtk/C extension - segfault
> Hi James,
>
> >
> > You didn't compile your cavfs module with debug info (or alternatively,
> > you passed -export-symbols-regex to an unpatched libtool when linking
> > your module). When this happens, gdb makes its best guess about what
> > function the stack frame refers to based on what it finds in the dynamic
> > symbol table. This often causes static functions to be mistaken for
> > visible symbols defined near by.
> >
> > Without the debug info, it is a lot more difficult to diagnose the
> problem.
> >
>
> I didn't, that's true, but my backtrace in gdb is complete so I assume
pygtk
> already contains a debug info.
> After sitting many hours on the problem I found it is caused by a
DEFINITION
> of a global variable!
> Strange, huh?
>
> Precisely:
>
> module cavfsmodule.c defines:
> static PyMethodDef cavfs_methods[] = {
> ...
> };
>
> module gwrapper.c defines:
> PyTypeObject *PyGObject_Type = NULL;
>
>
> Now, the segfault occurs, gdb says that cavfs_methods is called although
it
> is referenced just in the initialization method.
> If I change gwrapper.c to: "static PyTypeObject *PyGObject_Type = NULL;"
the
> segfault new happens.
>
> Finally, this seems to be a compilation problem, isn't it?
> Actually, I'm happy I found a way to avoid the problem. If someone has
> similar experience, please, let me know.
>
>
The library gobject.so contains a global variable PyTypeObject
*PyGObject_Type.
This leads to conflict and segfault. I'm not good enough to explain why, but
that's enough for me :)
Tobbi
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
