[Development] leak in QMetaObject?

[Thomas Senyk]

On 14.07.2016 17:18, André Somers wrote:
> 
> 
> Op 14/07/2016 om 17:10 schreef Olivier Goffart:
>> On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
>>> Hi,
>>>
>>> I lately wanted to validate that a connecting&disconnecting to a lambda
>>> will not leak the lambda object .. and found that more then that is
>>> leaked.
>>>
>>> Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
>>>
>>> After the 10million connections are executed and disconnected (all of
>>> them a successful), I assume a drop in memory consumption and more
>>> importantly a drop of cpu load to close to 0%.
>>>
>>> I see neither one nor the other. I see continues 100% consume with no
>>> memory consumption drop what so ever.
>>>
>>> I did a quick peak into QMetaObject::activate and it seems no clean up
>>> happened .. the list returned in
>>>    list = &connectionLists->at(signal_index);
>>>    (line #3660 in 5.6 checkout from today)
>>>
>>> seems rather long! (10million?)
>>>
>>> However all "if (!c->receiver)" shows no receiver and therefor will
>>> continue right away .. at least
>>>
>>> Is this expected? A bug? ... I'm happy to fill a bug report, I just
>>> wanted to get some feedback, maybe I'm just doing something wrong
>>
>> The lambda object and its capture is destroyed by the call to
>>    slotObj->destroyIfLastRef()
>>
>> The internal data structre (QObjectPrivate::Connection) is deleted by
>> QObjectPrivate::cleanConnectionLists which is actually only called when
>> a new connection is made to this object.
>>
>> I don't think there is a leak, but it is true that some memory is only
>> free'ed
>> when you add new connection or that the object is destroyed. (but the
>> lambda
>> object is destroyed right after the disconnection)

Then this:
http://paste.ofcode.org/37rxyitynhEqi5gira88hR9

should "fix" it? .. but I still see 100% cpu and same memory consumption?


>>
>>
>>> Some background:
>>> I wanted to check if a single-shot-connection (connection to a signal
>>> and disconnect at first execute, using a lambda as slot) would be a
>>> feasible thing to do.
>> You can do that already:
>>
>>   QTimer::sigleShot(100, [] { qDebug() << "hello"; });
>>
> That's not the same thing.
> This looks like my earlier suggestion
> https://bugreports.qt.io/browse/QTBUG-44219

+1, this is similar but not the same,

> 
> André
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development