Don't understand debugging..???

[johne53]

I'm using Code::Blocks under OpenSuse Linux. When I first downloaded C::B I tried a simple "Hello World" type app (writen in C++, using gcc compiler) and everything seemed fine. I was able to set breakpoints / single-step through the code etc.

Now I'm trying to debug a more complex project. I've definitely built a Debug version and I've set some breakpoints - but the debugger doesn't stop at them. I see this ouput in the debugger window....

Setting breakpoints
Debugger name and version: GNU gdb 6.5
Continuing...
No symbol table is loaded.  Use the "file" command.

So I've gone back to my simple 'Hello World' app and I can't get that to work either!!! I've updated C::B several times since I first installed it - so wither something's stopped working (unlikely) or there's something that I did last time that I've forgotten about in the interim.

Can anyone suggest a reason why my breakpoints don't work any more??

[johne53]

I can hardly believe this.... all of a sudden it's started working again - though not very well. For example, if I stop at a breakpoint, CTRL+F7 doesn't continue whereas dropping down the Debug menu and selecting 'Continue' does continue. Under Linux, I've had various problems in the past with CTRL. But I always found that F4 could be used in its place. So I tried pressing F4+F7 instead of CTRL+F7. This does cause the program to continue - but it also adds a strange 'Ś' character at the current cursor position. Also, stepping into a function (which I'd expect to be almost instantaneous) can take anywhere from 5 to 30 seconds. On top of those problems, I can't seem to set a new breakpoint whilst my app is running in the debugger. I have to stop it, set the breakpoint and then re-start.

Also, if I set a new breakpoint then re-start the debugger, a message box appears telling me that the default C::B layout has changed and asking if I want to save it. This gives me the impression that my breakpoints will get saved - but they aren't. If I close the session, then re-open it later, all my breakpoints have vanished.

Surely debugging can't be this bad with C::B and gdb..

[dempl_dempl]

Go to Project->Build Options . Check "-g" option ( Build with debugging symbols ).

If that doesn't do the job, use apt-get to upgrade and install all relevant code::blocks debs/rpms .

It worked for me.

[johne53]

Thanks. I already checked the -g option which is selected for every source file.

My real concern is the fact that this was working perfectly - then it wouldn't work at all - now it suddenly works very badly. When I first dowloaded C::B (in April) I did lots of tests on it and was hugely impressed. But each time I upgrade to a newer version it seems to get gradually less & less reliable. I now have features that work when they feel like it and a couple of bugs which are 100% repeatable for me but nobody else seems to be able to reproduce them.

The only things I've been updating are Code::Blocks itself and wxWidgets. Are there other elements that I should have been updating too?

I've tried updating from RPM's and also building from source (which required me to obtain wxWidgets_devel). But no matter how I updated C::B, wxWidgets was the only other thing I updated along with it. Should I have been doing more?

[Jenna]

have you tried to clean the sourcetree and rebuild your project (not just buil or rebuild), and unset (if set) all optimization and stripping for debug-target ?

[johne53]

Groan.... I've come back to Code::Blocks this morning and none of this is working again.. 

Sorry Jens - I was away for 2 days so I couldn't reply to your post but I must admit, I'm really disappointed now with Code::Blocks. 5 months ago it seemed rock solid - but now I seem to be saddled with a very erratic product that only works when it feels like it.

Two days ago, the debugger was working (albeit badly). Today, I can't get break points to work any more and I see the same messages that I reported in my original post. Nothing can possibly have changed because I've been away for 2 days.

To be honest, I don't think this is a project problem because I get the same results with different projects. However, I'll willingly try cleaning up my source tree for what it's worth. All optimizations are disabled for my debug targets but I don't understand what's meant by 'cleaning' the source tree. How/why should I do that? And what would it achieve that can't be achieved by a full project rebuild?

[Jenna]

Cleaning means simply rightclick on your project in the Manager (Projects Tab) and choose clean.
This should remove all object-files to enable a clean rebuild net time.
Sometimes choosing just rebuild seems not to work.
In the debug-target there should be no optimization and no symbol stripping of course.

[johne53]

Hi Jens - sorry to have left this for such a long time but as you know, I've been battling with other problems that turned out to be caused by the Code Completion plug-in (which I've now disabled).

I got to the stage where I'd reinstalled C::B on a completely different PC with a completely different Linux distro and I did a fresh svn checkout of this project's source files (I assume this to be just as good as cleaning the project).

On both my PC's the project builds perfectly and runs as expected (so long as I run it outside the debugger). But on both PC's, debugging is very erratic (in fact, currently non-existent on both machines). I've definitely built the Debug target and I checked that debugging symbols are enabled, no symbols are being stripped and there's no optimization.

If I load the project, then select Debug->Start (with no break points set) I would expect my application to launch. But what actually happens (on both machines) is that I see a message saying "The layout 'Code::Blocks default' has changed. Do you want to save it?". At this point, it makes no difference whether I select yes, no or cancel - the debugger starts in each case. However, the app being debugged never starts and I see a message in the Debugger window saying "No symbol table is loaded: Use the 'file' command". Should that mean something to me?

[BlueHazzard]

Hallo,

my english is not very god, but i have the same problem..... i'm using winxp and mingw with gdb.... and the latest nightly build

in the debug tab in the down of the screen is writen:

Code

PATH=.;C:\wxWidgets-2.8.6\lib\gcc_lib;C:\wxWidgets-2.8.3\lib\gcc_lib;C:\OgreSDK\bin\release;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\QuickTime\QTSystem\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\MinGW\bin\
Command-line: C:\MinGW\bin -nx -fullname  -quiet -args "bin/Release/Map Editor V2.exe"
Working dir : D:\Programmieren\Ogre\Map Editor V2\

i think there is missing gdb.exe in the "Command-line" line....

is this a bug??
thx

[johne53]

BlueHazzard - this is just a thought.... in your case, is the debug executable in its 'standard' output folder (i.e. bin/Debug) or have you changed the output folder? In my case I needed to change the target folder and since then, I haven't been able to get debugging to work for this project.

[Jenna]

@johne53
Have you ever tried to place the cursor on your first breakpoint and say run to cursor from menu.
Another problem is/was that gdb cannot stop on breakpoints in constructors (I don't know which version of gdb fixed this, or if it is fixed for Win).
If that's the problem you can call a dummy function dorm ctor and place the breakpoint in it and from there step through your code with F7.

[johne53]

@johne53
Have you ever tried to place the cursor on your first breakpoint and say run to cursor from menu.

Yes, I tried that but it didn't make a difference.

Another problem is/was that gdb cannot stop on breakpoints in constructors (I don't know which version of gdb fixed this, or if it is fixed for Win).

I must admit, I didn't know that. But some time ago (when it used to work) I successfully placed breakpoints inside a c'tor using gcc 4.1.1, so I assume it must have been fixed by then.

In fact, even if I don't have any break points at all, I would expect that Debug->Start would just launch my app - but it doesn't.... 

[Jenna]

"No symbol table is loaded: Use the 'file' command". Should that mean something to me?

Normally that means that there are no debugging symbols in the source file.
Is the "-g" option (Produce debugging symbols set in the Build options for the Debug target ?
You can also try to put "-gstabs+" in "Build options... -> Compiler Settings -> Other Options" instead of (or additionally to) using "-g" .

[johne53]

Good grief.... I decided to check on the actual version of gdb (rather than gcc) and it turns out that I'm using gdb version 6.5 - but guess what.... debugging is suddenly working this morning!!

I created the following 'Hello World' type app....

Code

#include <iostream>
#include <stdio.h>

int main()
{
char x;

    printf("Hello World\n"); // 1st breakpoint here
    printf("Hello Earth\n");
   printf("Hello Venus\n"); // and 2nd breakpoint here

    std::cin >> x;
    return (0);
}

I placed break points on the indicated lines. C::B consistently refuses to stop at the first break point - but it does stop at the second break point, every time!!

Knowing this, I loaded up the same project that I was trying to debug a couple of days ago and placed more than one breakpoint. Surprise, surprise - it suddenly works!! I haven't rebuilt the project or changed it in any way (in fact I haven't used C::B or Linux. I've been using VC++ under Windows for the past couple of days).

This is exactly the kind of unreliability that I mean.... If I just shut down and don't use Linux for the rest of today, I'm prepared to bet that it won't be working tomorrow!!

[Jenna]

Exactly the same here svn4561 on debian.

<Edit>
No, not exactly the same. Only with the simple example, not in a bigger wxWidgets project.
</Edit>

This is the source code:

Code

#include <iostream>

using namespace std;

int main()
{
    unsigned char c;
    cout << "Hello world!" << endl;
    cout << "Again, hello world!" << endl;
    cout << "Hey world, why don't you answer to my call!" << endl;
    cin >> c;
    return 0;
}

Breakpoints in Line 8 and 10

Works with gdb on console, but not in C::B.
In C::B it stops in line 10, but not line 8.

Here's the gdb.log from C::B:

Code

LD_LIBRARY_PATH=.:
Command-line: /usr/bin/gdb -nx -fullname  -quiet -args bin/Debug/test2
Working dir : /tmp/test2/
> set prompt >>>>>>cb_gdb:
Executing: xterm -T 'Program Console' -e sleep 88970
Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "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 /tmp/test2/
>>>>>>cb_gdb:
> break "/tmp/test2/main.cpp:10"
Breakpoint 1 at 0x8048a99: file /tmp/test2/main.cpp, line 10.
>>>>>>cb_gdb:
> break "/tmp/test2/main.cpp:8"
Breakpoint 2 at 0x8048a51: file /tmp/test2/main.cpp, line 8.
>>>>>>cb_gdb:
Executing: ps x -o tty,pid,command
PS result: tty3     32076 bash
PS result: tty3     32075 su jens
PS result: tty2     32068 bash
PS result: tty2     32067 su jens
PS result: tty1     32064 bash
PS result: tty1     32063 su jens
PS result: ?         9059 ps x -o tty,pid,command
PS result: pts/1     9058 sleep 88970
TTY is[/dev/pts/1]
GetConsoleTTY[/dev/pts/1]ConsolePid[9057]
> tty /dev/pts/1
Queued:[tty /dev/pts/1]
>>>>>>cb_gdb:
> start
Breakpoint 3 at 0x8048a51: file /tmp/test2/main.cpp, line 8.
[Thread debugging using libthread_db enabled]
[New Thread 0xb69b8a10 (LWP 9060)]
[Switching to Thread 0xb69b8a10 (LWP 9060)]
Breakpoint 2, main () at /tmp/test2/main.cpp:8
/tmp/test2/main.cpp:8:81:beg:0x8048a51
>>>>>>cb_gdb:
> info program
	Using the running image of child Thread 0xb69b8a10 (LWP 9060).
Program stopped at 0x8048a51.
It stopped at breakpoint 2.
It stopped at a breakpoint that has since been deleted.
Type "info stack" or "info registers" for more information.
>>>>>>cb_gdb:
> cont
Breakpoint 1, main () at /tmp/test2/main.cpp:10
/tmp/test2/main.cpp:10:162:beg:0x8048a99
>>>>>>cb_gdb:
> cont

In windows gdb works correctly (svn4551, W2K, MinGW 5.1.3 and gdb 6.3.2).

gdb's log from windows:

Code

PATH=.;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\MinGW\bin;C:\Programme\codeblocks
Command-line: C:\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/Debug/test2.exe
Working dir : C:\Dokumente und Einstellungen\Administrator\Eigene Dateien\new\test2\
> set prompt >>>>>>cb_gdb:
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.3
Copyright 2004 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 "i686-pc-mingw32".
>>>>>>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 debugevents on
>>>>>>cb_gdb:
> set new-console on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> directory C:/DOKUME~1/ADMINI~1/EIGENE~1/new/test2/
>>>>>>cb_gdb:
> break "C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/new/test2/main.cpp:10"
Breakpoint 1 at 0x401460: file C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/new/test2/main.cpp, line 10.
>>>>>>cb_gdb:
> break "C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/new/test2/main.cpp:8"
Breakpoint 2 at 0x401418: file C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/new/test2/main.cpp, line 8.
>>>>>>cb_gdb:
> run
Breakpoint 2, main () at C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/new/test2/main.cpp:8
C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/new/test2/main.cpp:8:84:beg:0x401418
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> cont
Breakpoint 1, main () at C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/new/test2/main.cpp:10
C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/new/test2/main.cpp:10:165:beg:0x401460
>>>>>>cb_gdb:
> cont
Program exited normally.
>>>>>>cb_gdb:
> quit

[BlueHazzard]

No, i didn't change anything....
i updated only gdb, but before it also didnt work.....

thx

[johne53]

Exactly the same here svn4561 on debian.

[...]

Breakpoints in Line 8 and 10

Works with gdb on console, but not in C::B.
In C::B it stops in line 10, but not line 8.

Maybe that's a good sign - at least is suggests C::B as being the possible cause. I hope that one of the developers can reproduce this and come up with an explanation - because it might get us nearer to understanding why C::B and gdb are so unreliable together.

<Edit>
No, not exactly the same. Only with the simple example, not in a bigger wxWidgets project.
</Edit>

That's what I'm finding too. Different projects suffer different problems and some don't seem to have any problems at all. The last bug I reported (inexplicable segfaults while closing C::B) turned out to be an errant plug-in. I really hope that someone will be able to track this one down because, for me at least, it's making C::B equally unreliable.

[Biplab]

Maybe that's a good sign - at least is suggests C::B as being the possible cause. I hope that one of the developers can reproduce this and come up with an explanation - because it might get us nearer to understanding why C::B and gdb are so unreliable together.

Just posting it doesn't work without providing any information or Unnecessarily ranting devs (assuming you are the Big-Boss) would yield nothing. If you're unable to provide any information related to the bug, then our answer is also simple - "It works for us".

Why don't you provide more info as Jens did? Your posts are always Full of Rants, FUDs (this doesn't work / that doesn't work, etc).

Did you ever try to find out why this problem exists when the same command-line works on Windows and doesn't work on Linux? But you have already opined that it's a C::B problem.

Can you tell me why the devs should "come up with an explanation"? Isn't that too rude??

If you find C::B too unreliable, why don't you make some efforts to make it a reliable one??

[Jenna]

<Edit>
Hi Biplap,
our posts crossed each other.
Here's a little more information:
</Edit>

I'm not sure, but I think I pointed out the problem:

gdb runs the program using the "start"-instruction.
That makes gdb stop at the begin of the "main"-function.
gdb automatically set a breakpoint (breakpoint 3 in snippet below), if it has stopped "info program" is called.
and then the "cont"-instruction is called.

I guess codeblocks "thinks" gdb stopped at automatically set breakpoint (what's right of course), and does not know (or does not remember or ignore) that the user has set a breakpoint at the same line.

If I set the first breakpoint at the second instruction in main codeblocks stops there as wanted.

Code

LD_LIBRARY_PATH=.:
>>>>>>cb_gdb:
> start
Breakpoint 3 at 0x8048a51: file /tmp/test2/main.cpp, line 8.
[Thread debugging using libthread_db enabled]
[New Thread 0xb69b8a10 (LWP 9060)]
[Switching to Thread 0xb69b8a10 (LWP 9060)]
Breakpoint 2, main () at /tmp/test2/main.cpp:8
/tmp/test2/main.cpp:8:81:beg:0x8048a51
>>>>>>cb_gdb:
> info program
	Using the running image of child Thread 0xb69b8a10 (LWP 9060).
Program stopped at 0x8048a51.
It stopped at breakpoint 2.
It stopped at a breakpoint that has since been deleted.
Type "info stack" or "info registers" for more information.
>>>>>>cb_gdb:
> cont

Short:
a breakpoint at the first instruction in main is ignored by codeblocks, because there is also an auto-breakpoint set by gdb's "start"-instruction.

<Edit2>
On windows gdb ist started with the "run"-instruction, which makes gdb run to the first breakpoint. So debugging works in this case as expected.
</Edit2>

[Biplab]

<Edit>
Hi Biplap,
our posts crossed each other.
Here's a little more information:
</Edit>

I'm not sure, but I think I pointed out the problem:

I'm also not sure about this. I faced this issue long back and I made a small change in the way breakpoints are added. That solved the issue.

Let me find out the patch. I'll post it. But I don't know why that patch works.

[Biplab]

@Jens,

Can you try this patch. If I remember correctly, it fixed that bug.

Code

Index: src/plugins/debuggergdb/debuggerstate.cpp
===================================================================
--- src/plugins/debuggergdb/debuggerstate.cpp	(revision 4563)
+++ src/plugins/debuggergdb/debuggerstate.cpp	(working copy)
@@ -337,8 +337,8 @@
     m_pPlugin->Log(_("Setting breakpoints"));
     m_pDriver->RemoveBreakpoint(0); // clear all breakpoints
 
-    i = (int)m_Breakpoints.GetCount() - 1;
-    while (i >= 0)
+    int j = (int)m_Breakpoints.GetCount() - 1;
+    for ( int i = 0; i <= j; ++i )
     {
         DebuggerBreakpoint* bp = m_Breakpoints[i];
         m_pDriver->AddBreakpoint(bp);

[Jenna]

@Biplap

I applied the patch, but I also remove the "--i" at the end of the loop.
If it stays, there would be an endless loop, "i" starts  with "0" is decreased at the last line of the loop by "--i" and then again increased by "++i" in the head of the for-loop.
So the code would only work if "j" is <= 0 (only one breakpoint).

[Biplab]

I applied the patch, but I also remove the "--i" at the end of the loop.
If it stays, there would be an endless loop, "i" starts  with "0" is decreased at the last line of the loop by "--i" and then again increased by "++i" in the head of the for-loop.
So the code would only work if "j" is <= 0 (only one breakpoint).

Thanks a lot for the change. Sorry I lost the original patch and I recreated it.

But did it work??

My Fedora installation doesn't have this problem. So I can't reproduce this bug on my PC.

[Jenna]

No it does not work.
The only thing that's different in the debugger-log is that the formerly bp with the number 1 is now 2 and vice-versa. But that is because the for-loop increases from 0 and the while-loop decreases to 0.
Adding breakpoints is not the problem I think.
I still believe the problem is that gdb stops automatically at the beginning of main and codeblocks does not recognize that there is also a user breakpoint set.

I try to debug it.

[johne53]

As I predicted yesterday, today it's stopped working again....    In fact, when I try to start the debugger today I get a dialog box saying "Select Target" which asks me to select either the Debug or Release build. Whichever target I select, the app (to be debugged) never starts.

Biplap - I appreciate that it must be frustrating when somebody reports an ongoing problem which you cannot reproduce - but equally, I cannot obtain any reproducable (or predictable) behavior. Some days it works, Other days it doesn't. Sometimes I see a particular dialog box (like the one I just described) other times I see some different dialog - like the one asking me to save the default layout before continuing. Some days I won't get any dialog at all. There's no pattern to the behaviour - it's unpredictable.

If I could give you something repeatable, I would (exactly like I did yesterday). In fact, as far back as Sept 22nd I posted this output which I see consistently on those occasions when the debugger fails to work at all:-

Code

Setting breakpoints
Debugger name and version: GNU gdb 6.5
Continuing...
No symbol table is loaded.  Use the "file" command.

That's just about all the feedback I get so I don't know what more I could give you.  Maybe tomorrow (without me changing anything) it'll suddenly start working again. i just never know....

[Biplab]

No it does not work.
The only thing that's different in the debugger-log is that the formerly bp with the number 1 is now 2 and vice-versa. But that is because the for-loop increases from 0 and the while-loop decreases to 0.
Adding breakpoints is not the problem I think.
I still believe the problem is that gdb stops automatically at the beginning of main and codeblocks does not recognize that there is also a user breakpoint set.

I try to debug it.

Thanks for the feedback. As I said earlier, it worked for me in the past; but I don't know why?

Biplap - I appreciate that it must be frustrating when somebody reports an ongoing problem which you cannot reproduce - but equally, I cannot obtain any reproducable (or predictable) behavior. Some days it works, Other days it doesn't. Sometimes I see a particular dialog box (like the one I just described) other times I see some different dialog - like the one asking me to save the default layout before continuing. Some days I won't get any dialog at all. There's no pattern to the behaviour - it's unpredictable.

If I could give you something repeatable, I would (exactly like I did yesterday). In fact, as far back as Sept 22nd I posted this output which I see consistently on those occasions when the debugger fails to work at all:-

I can understand your frustration. In Fedora 7, it works. I had this problem in my OpenSUSE box (which I don't use atm). So I suspect any other security app which is blocking gdb (Just a guess).

You can view the debugger log by turning on Settings > Compilers and debugger > Debugger settings > Display debugger's log. In this way you can get the debugger's output.

[johne53]

Actually, that was a very helpful suggestion (see output....)

LD_LIBRARY_PATH=.:/media/SHAREDDATA/ardour2/libs/pbd/:/media/SHAREDDATA/ardour2/libs/surfaces/control_protocol/:/media/SHAREDDATA/ardour2/libs/libsndfile/:/media/SHAREDDATA/ardour2/libs/midi++2/:/media/SHAREDDATA/ardour2/libs/ardour/:/media/SHAREDDATA/ardour2/libs/sigc++2/:/media/SHAREDDATA/ardour2/libs/glibmm2/:/media/SHAREDDATA/ardour2/libs/gtkmm2/atk/:/media/SHAREDDATA/ardour2/libs/gtkmm2/pango/:/media/SHAREDDATA/ardour2/libs/gtkmm2/gdk/:/media/SHAREDDATA/ardour2/libs/gtkmm2/gtk/:/media/SHAREDDATA/ardour2/libs/gtkmm2ext/:/media/SHAREDDATA/ardour2/libs/soundtouch/:/media/SHAREDDATA/ardour2/libs/libgnomecanvasmm/:
Command-line: /usr/bin/gdb -nx -fullname  -quiet -args bin/Release/ardour-2.0.5
Working dir : /media/SHAREDDATA/ardour2/gtk2_ardour/
> set prompt >>>>>>cb_gdb:
bin/Release/ardour-2.0.5: No such file or directory.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.5
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 "i586-suse-linux".
>>>>>>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 /media/SHAREDDATA/ardour2/gtk2_ardour/
>>>>>>cb_gdb:
> break "/media/SHAREDDATA/ardour2/gtk2_ardour/new_session_dialog.cc:123"
No symbol table is loaded.  Use the "file" command.
>>>>>>cb_gdb:
> start
No symbol table loaded.  Use the "file" command.
>>>>>>cb_gdb:
> quit

The above is from an instance where I got the message about no debug symbols found. Note that the debugger is trying to run my Release version!! Could this be something silly - like I haven't entered the path to my Debug copy? The working directory is also wrong. I've tried to find out where I can change those paths but I can't see anything obvious (e.g. in the project's Properties or Build Options).

Incidentally, I'm starting to think that the other problem I keep hitting (the dialog that keeps asking me to save my default layout) is possibly an unrelated bug. Today, that dialog has been intermittently appearing anyway, for no apparent reason. For instance, just now I opened C::B and immediately closed it without doing anything - but I still saw that dialog, telling me that my settings had changed (which they hadn't).

Another thing I've discovered today is that once the debugger starts working, it seems to carry on working until I next re-boot. Does this maybe suggest an uninitialised variable? i.e. once it gets correctly initialised, the debugger works fine from then on....

[Jenna]

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

Code

--- /usr/src/c/codeblocks/codeblocks-1.0svn/src/plugins/debuggergdb/gdb_driver.cpp      2007-10-27 21:29:40.000000000 +0200
+++ /home/jens/codeblocks-build/codeblocks-1.0svn/src/plugins/debuggergdb/gdb_driver.cpp        2007-10-28 04:02:19.000000000 +0100
@@ -456,7 +456,16 @@
         if (!Manager::Get()->GetConfigManager(_T("debugger"))->ReadBool(_T("do_not_run"), false))
         {
             // start the process
-            QueueCommand(new DebuggerCmd(this, remoteDebugging ? _T("continue") : _T("start")));
+            if(breakOnEntry)
+            {
+                QueueCommand(new DebuggerCmd(this, remoteDebugging ? _T("continue") : _T("start")));
+            }
+            else
+            {
+                // if breakOnEntry is not set, we need to use 'run' to make gdb stop at a breakpoint at first instruction
+                m_ManualBreakOnEntry=false;  // must be reset or gdb does not stop at first breakpoint
+                QueueCommand(new DebuggerCmd(this, remoteDebugging ? _T("continue") : _T("run")));
+            }
             m_IsStarted = true;
         }
     }
@@ -971,13 +980,15 @@
     {
         if (m_ManualBreakOnEntry)
         {
-            m_ManualBreakOnEntry = false;
             QueueCommand(new GdbCmd_InfoProgram(this), DebuggerDriver::High);
-            if (!m_BreakOnEntry)
-                Continue();
+        }
+        if (m_ManualBreakOnEntry && !m_BreakOnEntry)
+        {
+            Continue();
         }
         else
         {
+            m_ManualBreakOnEntry = false;
             wxString lineStr;
             if(platform::windows)
             {

[johne53]

Guys - I think I might have found at least one of the causes (BlueHazzard - can you try this on your machine and confirm..?)

When I launch C::B (I'm currently running svn4475) the Build Target happens to come up as Debug. If I modify a source file and ask C::B to build my target, it builds the Debug target, as I'd expect. However, if I press F8 (to start the debugger) C::B selects the Release target..! I've found that if I change my Build Target to 'Release' then change it back to 'Debug' the debugger will correctly start the Debug target. I don't yet know what's causing the spurious dialog boxes but could it be connected to this same problem? In other words, C::B thinks I changed from Debug target to Release target when in fact, I didn't?

Some time ago (approx svn 4454) I reported that the Build Target wasn't always being correctly restored (to its previous setting) after shutting down C::B and re-opening. This seemed to get fixed after I disabled the Code Completion plug-in, which was causing segfaults during C::B shutdown. However, maybe that was a coincidence and there's still a problem with the build target not being properly remembered.

[Jenna]

@johne53

I can partly confirm that.
If codeblocks (exactly the debugger plugin) doesn't find a valid target, it asks for the build target.

In fact, when I try to start the debugger today I get a dialog box saying "Select Target" which asks me to select either the Debug or Release build.

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.

The problem with the changed "default.conf" might be another 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).
The second is that the "entry8" and "entry9" inside the "auto_complete"-tag always get exchanged.
I can try to figure out the problem, but I am not at home the next week, because of work, and I will not have an Internet connection.
But the evenings in the hotel are mostly boring so I can do some debugging-sessions perhaps.

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

[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