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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
