Don't understand debugging..???

[Biplab]

If you select "Release" here, but in the toolbar there is "Debug" selected, codeblocks builds the Debug-version, but the debugger tries to debug the Release-version.
For me this goes away by either select "Release" and then reselect "Debug", as you wrote, or close and reopen codeblocks.

I'm not sure why the debugger sometimes thinks the project has no valid target. It happens when I open the codeblocks project-file (where no Debug and Release targets are included), switch between files and jump to a declaration, then close the project with "File -> Close all projects" and then open my test-project.
I think the active target should be taken from the taskbar, because this is the one taken from the projects layout-file, and when the target is changed in the debugger plugin, by selecting a target it would be more consistent if the taskbar also changes.

They are part of two different plugins. Toolbar for target selection belongs to Compiler plugin. But they should interact well with each other.

By the way is it possible to debug codeblocks from within codeblocks, or do I need an external-debugger(-gui).
It works with "kdbg" but it's not as comfortable as C::B. I also tried "insight" but ... 

You can debug C::B inside C::B (we do this).

I did a little debugging this night.
There another little bug in degbugging: when you start debugging with 'Step-Into' gdb breaks at start of main as it should, but the cursor did not change.

I created a patch that fix this bug and the problem, that gdb does not stop at first breakpoint if it's the first instruction in "main", or exactly it stops, queues "info program" and continues.

Another problem still is there: if code gets automatically rebuild "Step-Into" does not stop at beginning of "main" if no breakpoint is set.

Thanks a lot for the investigation and the patch. Please post them in Berlios so that they don't get lost.

[Jenna]

You can debug C::B inside C::B (we do this).

I thought so, but I'm not able to make it work.
I always get a message like this

Code

Cannot find resources...
Code::Blocks was configured to be installed in '/usr/src/c/codeblocks/codeblocks-1.0svn.patch/src/devel/share/codeblocks'.
Please use the command-line switch '--prefix' or set the CODEBLOCKS_DATA_DIR environment variable to point where Code::Blocks is installed,
or try re-installing the application...

I tried several prefixes, but none of them seems to work.

If I debug with kdbg I use a debug build made with "--configure ...", "make" and "make install" that works, but to change some code and try it is always a long way, because I have to leave kdbg first and recompile codeblocks and ...

[johne53]

They are part of two different plugins. Toolbar for target selection belongs to Compiler plugin. But they should interact well with each other.

So hopefully there might be a simple fix for this? It looks like the debugger is failing to take account of the currently selected Build Target when the debugging process gets initiated.... At least there's a simple workaround but it would be nice if this could be fixed. Do I need to report it as a bug?

if I open C::B and then close it without doing anything (no project is opened) no message-box appears, but two things are changed in "default.conf".
The first is the "Tip of the Day" of course, I think that's okay, but should not trigger the save confirmation message-box, but silently save default.conf if nothing other has changed, even when switching between layouts (mabe it does).

I'll try disabling Tip of the Day and see if my spurious message boxes disappear. Thanks. 


[Edit...] Well sadly, the answer is 'No' - disabling Tip of the Day doesn't get rid of the dialog boxes. However, there's an option to 'Stop pestering me' which does eliminate them (maybe you've already selected that option, Jens).

Incidentally - even when C::B correctly starts the debugger (i.e. with my Debug version) the working directory, reported in the debugger output window, is still the working directory from the Release target - when it should presumably be from the Debug target. Even if I manually change the execution's working directory (in my project's Debug properties) the debugger still reports the wrong working directory. Is this something that might as well get fixed at the same time?

[Jenna]

Thanks a lot for the investigation and the patch. Please post them in Berlios so that they don't get lost.

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

[Edit...] Well sadly, the answer is 'No' - disabling Tip of the Day doesn't get rid of the dialog boxes. However, there's an option to 'Stop pestering me' which does eliminate them (maybe you've already selected that option, Jens).

No I did not disable it, I like to be asked whether the files should be saved or not.

[kylemallory]

I'm having a similar type debugging experience, but not identical.

I am trying to debug a shared library in an external application.  I've just barely installed Code::Blocks for the first time, so its entirely likely that my issue is simply noob-related.

When the debugger starts, I get "(no debugging symbols found)".  Looking at the debug log, it looks like its doing everything correctly... just no debug info.

I've double checked my project and build settings to make sure debug (-g) info is turned on, and that I'm not striping symbol data from the binaries, but still no go.

Below is the debugger log.

Is there anyway to get similar type log from gcc and ld?  to know exactly what command-line options they are being sent?

Code

LD_LIBRARY_PATH=.:
Command-line: /usr/bin/gdb -nx -fullname  -quiet -args /home/kmallory/ifx/bin/piranha
Working dir : /home/kmallory/workspace/AVCodec/
> set prompt >>>>>>cb_gdb:
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set disassembly-flavor intel
>>>>>>cb_gdb:
> directory /home/kmallory/workspace/AVCodec/bin/debug
>>>>>>cb_gdb:
> directory /home/kmallory/workspace/AVCodec/
>>>>>>cb_gdb:
> set args -w -m bin/debug/avcodec.so
>>>>>>cb_gdb:
> break "/home/kmallory/workspace/AVCodec/avcodec.c:539"
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> break "/home/kmallory/workspace/AVCodec/avcodec.c:592"
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> break "/home/kmallory/workspace/AVCodec/avcodec.c:556"
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> break "/home/kmallory/workspace/AVCodec/avcodec.c:567"
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> start
Breakpoint 1 at 0x82ba932
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1226144032 (LWP 8380)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Switching to Thread -1226144032 (LWP 8380)]
0x082ba932 in main ()
>>>>>>cb_gdb:
> bt 30
#0  0x082ba932 in main ()
>>>>>>cb_gdb:
> whatis n
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> output n
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> output n
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> output n
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> tbreak "/home/kmallory/workspace/AVCodec/avcodec.c:538"
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> cont
Support Directory is /home/kmallory/ifx/piranha
(no debugging symbols found)
(no debugging symbols found)
Unable to open wacom tablet (stylus)
Kiari Version 1.2.2 - Copyright 2006 Interactive Effects
HardwareFX Version 1.0.0-r7
File /home/kmallory/.piranha/piranha/prefs//deck_jericho not available
SPFX: error reading file ./bin/debug/avcodec.so
Error loading module ./bin/debug/avcodec.so: undefined symbol: av_openread
This license will expire in 1 day.
The hostid for this workstation is 00:15:c5:4f:73:43
Unknown format of the requested file /media/VIDEO VAULT/DRTN Color Pass/DeathR06V01.430158D8.E68790.omf.avi
Unknown format of the requested file /media/VIDEO VAULT/DRTN Color Pass/DeathR06V01.4301582A.BC2120.omf.avi
Unknown format of the requested file /media/VIDEO VAULT/DRTN Color Pass/DeathR06V01.430157F4.AF05B0.omf.avi
Unknown format of the requested file /media/VIDEO VAULT/OMFI MediaFiles/white1127436552V043335108.omf
Piranha Autosave: Unable to write Desktop.autosave
Unknown format of the requested file /media/VIDEO VAULT/OMFI MediaFiles/DeathR03A02.430139C2.4F98F0.aif
This program requires a configured network card
Program exited with code 0377.
>>>>>>cb_gdb:
> quit

Thanks,

Kyle

[Jenna]

Thanks a lot for the investigation and the patch. Please post them in Berlios so that they don't get lost.

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

At least registration works  .

The patch is posted as Patch #2225.

[johne53]

I can understand your frustration. In Fedora 7, it works. I had this problem in my OpenSUSE box (which I don't use atm).

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.
Symbol Table Plugin (1.0)
ThreadSearch (1.5)


OS: Windows XP Pro SP2
Intel Core 2 Duo 6400