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

Alexis Boutillier alexis.boutillier at arteris.com
Tue Apr 14 11:39:03 BST 2009


Hi,

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 
types.
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:
>> 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
> 


-- 
Boutillier Alexis
Methodology engineer

Arteris SA
The Network-on-Chip Company TM
www.arteris.net

6 par Ariane Immeuble Mercure
78284 Guyancourt Cedex
France
Office: (+33) 1 61 37 38 71
Fax:    (+33) 1 61 37 38 41
Alexis.Boutillier at arteris.net


More information about the PyQt mailing list