Author Topic: The deadlock still exists in 17.12  (Read 487 times)

Offline dfatcb

  • Multiple posting newcomer
  • *
  • Posts: 52
The deadlock still exists in 17.12
« on: September 07, 2018, 08:58:42 pm »
Hello,

Years ago I came across an issue where I'd try to build the main library and it deadlocks (spinning icon and cpu by codeblocks at 100%).  I'd have to open codeblocks, open the project, then wait a while, then build and it would work, if I did it too fast it could deadlock.   So at some point that cleared up, and updated versions, and now even updated to 17.12 for debugging (a lot of times the stack frame goes away, still does that too, just not as much, much more stable).   Anyway, all of a sudden that deadlock is back.  I think I know what it's related to.   If I do it too fast and the drop downs (code completion) at the top that have to do with showing the classes and items.  If I wait until after that populates, there never seems to be a lock, if I start before then, unless <none> would show up, it dead locks at the point where it would populate it (via about the same timing) - it stays blank.    I have to end the process, then go back in and wait, and it shows up with some classes/structures in the list, then compile and it works.

Hope that helps!!


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11188
    • Travis build status
Re: The deadlock still exists in 17.12
« Reply #1 on: September 07, 2018, 10:23:34 pm »
1. What os are you using?
2. Can you reproduce this in a minimal project?
3. Can you post a backtrace/callstack from all threads when a dead lock happens?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline dfatcb

  • Multiple posting newcomer
  • *
  • Posts: 52
Re: The deadlock still exists in 17.12
« Reply #2 on: September 17, 2018, 05:57:40 pm »
It's transitioned across the Debian line, from squeeze (original issue), to wheezy (didn't have many)  to now jessie (after fsck ran).    It's hard to reproduce, I only noticed it's when that dropdown on the tool bar populates (little flicker and either okay if <none> or hang if occurs doing actual build process). Right now, I just wait a moment before building to ensure that has happened.  I should be able to get a trace -  what is the command to get it?


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11188
    • Travis build status
Re: The deadlock still exists in 17.12
« Reply #3 on: September 17, 2018, 06:16:07 pm »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline cacb

  • Regular
  • ***
  • Posts: 374
Re: The deadlock still exists in 17.12
« Reply #4 on: September 19, 2018, 03:55:10 pm »
2. Can you reproduce this in a minimal project?

I don't think you can reproduce in a minimal project. I think it happens in project with some significant size. I have seen this myself on some of my workspaces with 10+ projects and significant amount of code. Like dfatcb I suspect it has to do with code completion (a background thread that needs to complete?). If you wait when you open a workspace there is usually no issue, but if you are too quick you may experience a total freeze requiring a C::B restart.

I have seen it on Windows (7 and 10) at least. Not 100% sure about linux (Kubuntu), but probably there as well. Code::Blocks 17.12

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11188
    • Travis build status
Re: The deadlock still exists in 17.12
« Reply #5 on: September 19, 2018, 05:43:58 pm »
Deadlocks are easy to diagnose if you have builds with symbols. The "thread apply all bt" gdb command will show it for sure.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]