We have an upstream crash report [0] (backtrace [1]) in KInotify::Private::_k_addWatch when checking whether dirIterators QQueue is empty. This is a regression introduced by fix [2] of bug 305685 [0] https://bugzilla.redhat.com/show_bug.cgi?id=858271 [1] https://bugzilla.redhat.com/attachment.cgi?id=614030 [2] http://commits.kde.org/nepomuk-core/d16e80a9e4ad6e947f5618e05e33d3267609a0dd Reproducible: Sometimes
> We have an upstream crash report s/upstream/downstream/ ;-) But I don't see how this would crash when the previous version didn't, given how the next line wants to take the first element of the same list! If even isEmpty crashes, how can that not have crashed?
*** Bug 306573 has been marked as a duplicate of this bug. ***
reverting http://commits.kde.org/nepomuk-core/d16e80a9e4ad6e947f5618e05e33d3267609a0dd doesn't fix it for me.
Yeah, that commit can't possibly be guilty. Hussam, or anyone else who is compiling from sources and hitting this bug: can you run the process in valgrind, in order to get a valgrind log of the crash? This would be something like killing the running nepomukfilewatch, 5 times in a row (to disable the automatic restart) and then: valgrind --partial-loads-ok=yes nepomukservicestub nepomukfilewatch
Created attachment 74183 [details] valgrind log valgrind log. I'm not sure I did this correctly. it not, let me know please :)
Will I break anything if I compile the nepomuk-core 4.9.0 package and install it instead of 4.9.1?
just to check if this fixes things.
Thanks for the valgrind trace, that helps. http://www.davidfaure.fr/2012/nepomukfilewatch.cpp.diff should fix it, please test.
Patch applied, segfault eliminated - thank you very much! Plus, I can only reiterate the awesomeness of /etc/portage/patches :)
seems fixed here too. thank you :)
Git commit 804e54f83ade8a377d392d350981ead07f60a9d3 by David Faure. Committed on 02/10/2012 at 20:27. Pushed by dfaure into branch 'KDE/4.9'. Fix crash when watchUserLimitReached() leads to deleting the KInotify instance ... which emitted the signal. So don't use a direct delete. FIXED-IN: 4.9.3 M +2 -1 services/filewatch/nepomukfilewatch.cpp http://commits.kde.org/nepomuk-core/804e54f83ade8a377d392d350981ead07f60a9d3
Unfortunately, your fix is not sufficient. We've just gotten this crash report from the build with your fix: https://bugzilla.redhat.com/show_bug.cgi?id=862369 I think this probably needs an if (m_dirWatch) check around the m_dirWatch->deleteLater(); call (delete automatically checks for NULL, deleteLater() is a method and so it won't work if you call it on NULL).
Git commit 32b44881dda4f243932c59c11bf39c91f30c224b by Dan Vrátil. Committed on 03/10/2012 at 13:27. Pushed by dvratil into branch 'KDE/4.9'. Add null-crash guards for m_dirWatch to FileWatch M +8 -3 services/filewatch/nepomukfilewatch.cpp http://commits.kde.org/nepomuk-core/32b44881dda4f243932c59c11bf39c91f30c224b