D3977: Fix memleak in KDynamicJobTracker, KWidgetJobTracker needs QApplication
Elvis Angelaccio
noreply at phabricator.kde.org
Sun Oct 15 21:48:14 UTC 2017
elvisangelaccio added a comment.
In https://phabricator.kde.org/D3977#155762, @kossebau wrote:
> On a quick look the automatic unregistering based on the finished signal seems to make sense for any KJob subclass. Perhaps the change in this commit conflicts with some older code in Ark to work around the old behaviour and which does some additional manual unregistration? Or perhaps some slot in accidentally invoked 2x so the unregistration happens more than once, with the second try than failing? Wild guesses is all I have to offer, sorry. I cannot remember anything questionable about this patch, so no pointers into it, instead my initial reaction would be to look at the consumer side.
Yes Ark has a manual unregistration, which I can easily fix.
From what I can see, after this change any job registered with
KIO::getJobTracker()->registerJob(job);
no longer needs to be manually unregistered with
KIO::getJobTracker()->unregisterJob(job);
This is a minor thing, but should probably be documented somewhere.
REPOSITORY
R241 KIO
REVISION DETAIL
https://phabricator.kde.org/D3977
To: kossebau, #frameworks, kfunk
Cc: elvisangelaccio, kfunk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20171015/942392e2/attachment.html>
More information about the Kde-frameworks-devel
mailing list