| Summary: | nepomukservicestub crashed | ||
|---|---|---|---|
| Product: | [Unmaintained] nepomuk | Reporter: | Jan Binder <wheel> |
| Component: | general | Assignee: | Nepomuk Bugs Coordination <nepomuk-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | bladud |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/nepomuk-core/e9e907290bddcd9121e8a9e937198568699bc698 | Version Fixed In: | 4.10 |
| Sentry Crash Report: | |||
|
Description
Jan Binder
2012-10-21 22:24:16 UTC
From lines 6 and 7 of the backtrace in thread 1, it seems as if the destructor for a Folder object is somehow calling itself (notice the 'this' pointer is the same in both lines). It's not surprising that leads to a crash, but it is a bit surprising that it is possible at all... It seems we are almost guaranteed to call deleteLater() on the Folder object from its destructor. The Qt docs claim that it is safe to call deleteLater() multiple times, and they must be telling the truth, or this crash would happen consistently. But it is possible that whatever variable is checked to ensure the QObject is not already deleted is only set at the end of the destructor. In which case, there would be a small window between deleteLater() being called and ~Folder finishing during which the event loop could fire the deletion and cause this crash, especially if the system was under load, as yours seems to have been, which could be the cause of the crash. Git commit e9e907290bddcd9121e8a9e937198568699bc698 by Simeon Bird. Committed on 16/11/2012 at 01:28. Pushed by sbird into branch 'master'. Fix convoluted crash on deletion of Query::Folder. Sequence of events seems to be: 1. Folder::~Folder called. 2. SearchRunnable->cancel called => SearchRunnable->m_folder = 0. 3. Deletes all connections. 4. deleteLater called again, during destructor (is this ever safe?) 5. SearchRunnable::run called => since m_folder is zero, returns and deletes SearchRunnable without setting m_folder -> SearchRunnable to zero. 6. mutex unlocked at end of destructor 7. Folder::~Folder called again by queued deleteLater (?) 8. SearchRunnable already deleted after step 5. Crash. Fixed by setting m_currentSearchRunnable = 0 after cancelling the folder listing. FIXED-IN: 4.10 REVIEW: 107339 M +7 -2 services/storage/query/folder.cpp http://commits.kde.org/nepomuk-core/e9e907290bddcd9121e8a9e937198568699bc698 |