User forums > Using Code::Blocks
Don't understand debugging..???
Jenna:
--- Quote from: jens on October 28, 2007, 11:40:23 pm ---
--- Quote from: Biplab on October 28, 2007, 02:10:06 pm ---Thanks a lot for the investigation and the patch. Please post them in Berlios so that they don't get lost. :)
--- End quote ---
I tried to register at berlios today, but they did not send the activation email. There is an option to resend mail, but this also does not work. Sometimes they say mail is sent, sometimes theres an error message about being unable to connect to database.
I will not be at home the next week until thursday or friday, without internet as I wrote, so I can't post the patch in Berlios before next weekend ( if the berlios system feels better until then :) ).
--- End quote ---
At least registration works :D.
The patch is posted as Patch #2225.
johne53:
--- Quote from: Biplab on October 27, 2007, 03:16:03 pm ---I can understand your frustration. In Fedora 7, it works. I had this problem in my OpenSUSE box (which I don't use atm).
--- End quote ---
I'm also coming to the conclusion that OpenSuse is the problem. I've now tried debugging 2 x mutithreaded projects (one simple and one complex). In both cases, the app (being debugged) misbehaves, under OpenSuse, as soon as any breakpoint gets reached.
However, on my laptop, I've installed a different distro (64studio which, I gather, is a re-badged verison of Debian Etch). To my delight, the debugger works exactly as expected with both apps!!
Naturally there are big hardware differences - and another obvious difference is that the laptop is running gdb 6.4, compared to 6.5 on my desktop machine.
Maybe I should just cut my losses and install 64studio on my desktop machine too. :)
Thanks for everyone's help.
johne53:
Well, over Christmas, I installed 64studio on my desktop PC but source level debugging is as bad as ever. In fact, it turned out to be quite erratic on my laptop too (which had initially shown a lot of promise). But for all those people, like me, who've been pulling their hair out over this, here (I think) is the answer....
http://www.sourceware.org/ml/gdb/2006-03/msg00170.html
It seems to be a fairly authoritative explanation of why you can't debug a multi-threaded application on a POSIX based system. I guess this is one of those closely guarded secrets that no-one really wants to talk about.... :(
Disappointingly, one of the contributors suggests that it would be relatively simple to fix this in the kernel (and the fix is implemented routinely for new system calls) - but nobody's got the courage to change the old calls in case there are unpredictable side-effects.
Patuti:
For historical purposes, the bug is still there...
I'm not able to tell exactly when c::b loses track for which target gdb should start but it's trying to start the Release version when we've selected Debug target, even if we (when I say we is because the bug already happened to two colleagues that use c::b) restart c::b it's trying to start the wrong target (as you can see in the previous post, you can check the full debugger log) and switching targets and building again will solve the problem.
I'm using Code::Blocks 8.02 Build: Feb 27 2008, 20:59:09 - wx2.8.7 (Windows, unicode)
The following plugins are activated:
Code completion (0.7)
Code snippets (1.2.113 2008/01/24)
Compiler (0.99)
Debugger (0.3)
Environment Variables (0.97)
Files extension handler (1.0)
Keyboard shortcuts (1.0.46 2008/02/12)
Open files list (1.0)
Scripted Wizard (0.8)
Symbol Table Plugin (1.0)
ThreadSearch (1.5)
OS: Windows XP Pro SP2
Intel Core 2 Duo 6400
Navigation
[0] Message Index
[*] Previous page
Go to full version