[PyQt] CoreDump when calling slot with 'const char*' arguement
phil at riverbankcomputing.com
Tue Apr 14 11:28:44 BST 2009
On Thu, 09 Apr 2009 19:29:18 +0200, Alexis Boutillier
<alexis.boutillier at arteris.com> wrote:
> I'm having a core dump when connecting a signal define in a PyQt wrapped
> c++ class to a python method.
> The c++ signal have (const char*, int, int, int, int) as arguments.
> I investigate the core and found that the problem is in the conversion
> from c++ types to python types:
> in #11 0x00726c94 in PyQtProxy::invokeSlot (slot=@0x91104f4,
> qargs=0xbfffac24) at qpycore_pyqtproxy.cpp:444
> A tuple is filed with the C++ element converted to python.
> Looking at the element in the tuple, the "int" are correctly added but
> the "const char *" is not (can't print it with
> Looking further, in PyObject *Chimera::toPyObject(void *cpp) const,
> The "int" parameters have the metatype 2 corresponding to QMetaType::Int
> which is OK
> But the "const char *" have metatype 256 which is PyQt_PyObject::metatype
> Looking at what was done in PyQt 4.4.4, in PyQt 4.5.xxxx there is no
> call to PyString_FromString to convert a "const char*" is it done by the
> sipConvertFromType(cpp, _type, 0);
> Can someone help me for where to continue investigate this problem ?
Is this new code or did it work with PyQt v4.4.4?
I'm not sure yet what the right behaviour is in this case ( need to think
about it), but I think you can avoid the problem with a better API. You
should use either QString or QByteArray instead of const char *. That would
mean that you can safely use the signal across threads and not have to
worry about who owns the underlying data and whether it remains valid.
More information about the PyQt