Don't understand debugging..???

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