| Summary: | closed loop in Bucket::deleteItem (itemrepository.h) | ||
|---|---|---|---|
| Product: | [Developer tools] kdevplatform | Reporter: | RJVB <rjvbertin> |
| Component: | general | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | Keywords: | investigated, triaged |
| Priority: | NOR | ||
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | macOS | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=379669 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
do you mean while (currentIndex != index && currentIndex != previousIndex) ? does this fix the shutdown issue? could you recompile in debug mode to check the state and whether this helps? Yes, I meant something like that. I added a patch at the end of the loop that's a bit more of a hack
if(currentIndex == previousIndex){
currentIndex = index;
}
That did not immediately resolve the hang, so I added a qDebug statement to follow index and currentIndex.
Believe it or not, after that the session has been exiting correctly, without currentIndex ever getting stuck on a fixed value.
Don't you just love Heisenbugs ...
I'm leaving in that print-out, in case the issue ever returns.
Can this have been related to a corrupt cache? Or is whatever this class does in any way related to data returned from KIO's ioslaves or other components?
FTR: I'm experiencing this a lot on Linux as well. (In reply to Kevin Funk from comment #3) > FTR: I'm experiencing this a lot on Linux as well. The next person to experience this should probably post a backtrace. I regret not having done that; I didn't realise that the function is a template and apparently called from many locations. Would it be doable to catch `QCoreApplication::aboutToQuit()` and store it in a globally accessible location (if such a feature doesn't already exist) so that it becomes possible to trace the loop variables at exit only? Still waiting on suggestions how to fix or avoid this situation. *** This bug has been marked as a duplicate of bug 379669 *** This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change. |
I currently have a session that ends up in a closed loop at exit systematically, in the following block in itemrepository.h: ``` //Fix the follower-link by setting the follower of the previous item to the next one, or updating m_objectMap while(currentIndex != index) { previousIndex = currentIndex; currentIndex = followerIndex(currentIndex); //If this assertion triggers, the deleted item was not registered under the given hash Q_ASSERT(currentIndex); } Q_ASSERT(currentIndex == index); ``` all loop variables are optimised away, but I think that loop has 1 glaring omission of an end-condition : `previousIndex == followerIndex(currentIndex`. Reproducible: Always Steps to Reproduce: 1. open an affected session 2. sit back and wait until all activity ends 3. quit KDevelop without doing anything else Actual Results: KDevelop burns CPU Expected Results: KDevelop exits normally When I attach a debugger and jump to the assert on line 552 immediately after the loop, a normal exit follows.