Bug 363861 - closed loop in Bucket::deleteItem (itemrepository.h)
Summary: closed loop in Bucket::deleteItem (itemrepository.h)
Status: RESOLVED DUPLICATE of bug 379669
Alias: None
Product: kdevplatform
Classification: Developer tools
Component: general (show other bugs)
Version: git master
Platform: Compiled Sources macOS
: NOR crash
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords: investigated, triaged
Depends on:
Blocks:
 
Reported: 2016-06-02 20:57 UTC by RJVB
Modified: 2018-09-19 14:36 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description RJVB 2016-06-02 20:57:31 UTC
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.
Comment 1 Milian Wolff 2016-06-02 21:15:29 UTC
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?
Comment 2 RJVB 2016-06-02 21:40:21 UTC
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?
Comment 3 Kevin Funk 2016-06-02 22:13:11 UTC
FTR: I'm experiencing this a lot on Linux as well.
Comment 4 RJVB 2016-06-03 21:19:59 UTC
(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?
Comment 5 RJVB 2017-05-09 19:34:19 UTC
Still waiting on suggestions how to fix or avoid this situation.

*** This bug has been marked as a duplicate of bug 379669 ***
Comment 6 Andrew Crouthamel 2018-09-19 14:36:54 UTC
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.