[PyQt] CoreDump when calling slot with 'const char*' arguement
alexis.boutillier at arteris.com
Tue Apr 14 16:45:50 BST 2009
I was able to work around the problem by wrapping the signal arround
another one using QString instead of const char *.
Alexis Boutillier a écrit :
> The same code was working well in PyQt 4.4.4. with Qt 4.4.3.
> We found this problem in the process of migrating to new version 4.5 of
> Qt using PyQt snapshot.
> While reading the comments and documentation, I understand that QString
> and QByteArray have better support (encoding, ...). The problem is that
> this code is not writen by us and so I can't easily change the signal
> I will try to do a wrapper to use QString instead of char *.
> Thanks for the response.
> Phil Thompson a écrit :
>> 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
>>> 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
>> 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.
The Network-on-Chip Company TM
6 par Ariane Immeuble Mercure
78284 Guyancourt Cedex
Office: (+33) 1 61 37 38 71
Fax: (+33) 1 61 37 38 41
Alexis.Boutillier at arteris.net
More information about the PyQt