Review Request 113471: Fix crash when removing an item while we are adding one

Albert Astals Cid aacid at kde.org
Sun Oct 27 16:15:38 GMT 2013



> On Oct. 27, 2013, 11:05 a.m., Christoph Feck wrote:
> > Ah, that makes sense, thanks for your investigation!
> > 
> > What could be done to improve it, is to let the timer fire again sometimes later, until the item could actually be removed. I am not sure, though, if it is needed, in other words, what happens when items do not get removed by the timer.
> > 
> > But since this seems to workaround the crash, it should get into 4.11.3. Someone else must approve.
> 
> Albert Astals Cid wrote:
>     Well, the timer will trigger again 10 minutes later, and this is just for "cleaning up" the list a bit, so at most you'll have a few more notifications for a while, won't cause anything bad.
> 
> Christoph Feck wrote:
>     The timer says "repeat: false", and if it is triggered again, probably on a different "index"?

the timer will trigger again when idleTimeSource.idle changes from false to true to false, and if that never happens the notification will still be eventually removed by the addNotification code


- Albert


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113471/#review42418
-----------------------------------------------------------


On Oct. 27, 2013, 10:36 a.m., Albert Astals Cid wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113471/
> -----------------------------------------------------------
> 
> (Updated Oct. 27, 2013, 10:36 a.m.)
> 
> 
> Review request for kde-workspace, Plasma, Àlex Fiestas, and Michael Zanetti.
> 
> 
> Bugs: 311871
>     http://bugs.kde.org/show_bug.cgi?id=311871
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> -------
> 
> Reading https://bugs.kde.org/show_bug.cgi?id=311871#c41 you can see that it happens that we are doing a 
> #78 0x00007f4eff8c5ffb in QDeclarativeListModel::insert (this=0x1ebbdb0, index=0, valuemap=...) at util/qdeclarativelistmodel.cpp:436
> and then we end up reentring and doing 
> #16 0x00007f4eff8c737f in QDeclarativeListModel::remove (this=0x1ebbdb0, index=6) at util/qdeclarativelistmodel.cpp:402
> 
> Some of the stuff that depends on the QDeclarativeListModel doesn't seem to like getting a "remove" while a "insert" is happening and to be honest m in no mood to fix that, so basically I'm protecting against that happening in our QML code. From what i read you have to be extremely unlucky since the timer  only triggers each 10 minutes and it has to trigger at the same time a notification is being added, but oh well, the backtrace points to it and two different people in two different systems say it has stopped the crashes so I don't think it hurts to have this in.
> 
> 
> Diffs
> -----
> 
>   plasma/generic/applets/notifications/contents/ui/NotificationDelegate/NotificationDelegate.qml bf33eb1 
>   plasma/generic/applets/notifications/contents/ui/Notifications.qml 114ead2 
> 
> Diff: http://git.reviewboard.kde.org/r/113471/diff/
> 
> 
> Testing
> -------
> 
> I can't reproduce it in my desktop but Alex and Michael have been running this patch for weeks and can certainly say that the crashing situation has improved (i.e. no crashes in days with this patch and crashes daily without it).
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20131027/0fd7d903/attachment.htm>


More information about the kde-core-devel mailing list