User forums > Using Code::Blocks
Don't understand debugging..???
Biplab:
--- Quote from: jens on October 27, 2007, 01:37:59 pm ---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.
--- End quote ---
Thanks for the feedback. As I said earlier, it worked for me in the past; but I don't know why? :)
--- Quote from: johne53 on October 27, 2007, 02:39:07 pm ---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:-
--- End quote ---
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....)
--- Quote ---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
--- End quote ---
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)
{
--- End code ---
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.
--- Quote ---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.
--- End quote ---
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 ... :(
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version