[PyQt] CoreDump when calling slot with 'const char*' arguement

[Phil Thompson]

On Thu, 09 Apr 2009 19:29:18 +0200, Alexis Boutillier
<alexis.boutillier at arteris.com> wrote:
> Hi,
> 
> 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 
> PyString_AsString(PyObject_Repr)))
> 
> 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.

Phil