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.
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.