[PyQt] SIP: memory leak in mapped type?

[Giovanni Bajo]

On 7/27/2007 3:19 PM, Phil Thompson wrote:

>>          // Get the Python wrapper for the Type instance, creating a new
>>          // one if necessary, and handle any ownership transfer.
>>          if ((pobj = sipConvertFromInstance(cpp, sipClass_TYPE,
>> sipTransferObj)) == NULL)
> 
> Using sipConvertNewFromInstance() is preferable.

I suggest you updated the examples in the SIP documentation, then.

>>          {
>>              // There was an error so garbage collect the Python list.
>>              Py_DECREF(l);
> 
> delete cpp?

Right.

>> But then, I was wondering about the semantic of sipTransferObj. The
>> documentation isn't very clear about its usage. In fact, it's not clear
>> in this case whether it should apply to the whole vectors or to the
>> individual objects in the vector.
> 
> What it applies to is entirely up to you. In PyQt it always applies to the 
> individual elements.

Then, I haven't understood what "sipTransferObj" is or mean. Would you 
please explain it again from scratch? I have totally lost track of its 
meaning. Who sets its value? On which conditions? What it should apply to?

>> Does the fix make sense?
> 
> No.
>> And if so, why it isn't required in the SIP 
>> documentation example? And finally, with the above patch, the value of
>> sipTransferObj is totally ignored by the code: how can that be right?
> 
> For it to have any effect you must have used one of the Transfer annotations 
> on an argument or result of type std::vector<>. That will cause extra element 
> references to be taken - maybe that's not appropriate?

I'm not sure what you mean.

Please, have a look at the attached testcase. It shows two different (or 
related?) memory leaks:

- bug.h / bug.cpp is the source code, with two functions with identical 
semantic but different signature.
- bug.sip is the trivial wrapper for both functions.
- stl.sip is the file with the mapped types for std::vector [notice that 
most of it should be builtin in SIP in my humble opinion, but this is a 
discussion for another day].
- bug.py triggers the memory leak. You can choose which function to test 
in it. Both of them cause the leak.

To compile, "setup.py build_ext --inplace".
-- 
Giovanni Bajo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sipleak.zip
Type: application/octet-stream
Size: 3468 bytes
Desc: not available
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20070727/6465562f/sipleak.obj