Author Topic: Don't understand debugging..???  (Read 30108 times)

Offline johne53

  • Regular
  • ***
  • Posts: 253
Don't understand debugging..???
« on: September 22, 2007, 01:27:16 pm »
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....

Quote
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??

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Don't understand debugging..???
« Reply #1 on: September 22, 2007, 06:10:48 pm »
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

  • Guest
Re: Don't understand debugging..???
« Reply #2 on: September 23, 2007, 04:07:48 am »
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.

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Don't understand debugging..???
« Reply #3 on: September 23, 2007, 07:59:15 am »
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?

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Don't understand debugging..???
« Reply #4 on: September 23, 2007, 10:49:49 am »
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 ?

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Don't understand debugging..???
« Reply #5 on: September 25, 2007, 10:49:51 am »
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?
« Last Edit: September 25, 2007, 10:53:41 am by johne53 »

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Don't understand debugging..???
« Reply #6 on: September 25, 2007, 11:50:24 am »
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.

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Don't understand debugging..???
« Reply #7 on: October 24, 2007, 10:41:05 am »
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?

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: Don't understand debugging..???
« Reply #8 on: October 24, 2007, 05:02:25 pm »
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

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Don't understand debugging..???
« Reply #9 on: October 26, 2007, 07:04:02 am »
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.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Don't understand debugging..???
« Reply #10 on: October 26, 2007, 07:56:09 am »
@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.

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Don't understand debugging..???
« Reply #11 on: October 26, 2007, 08:24:17 am »
@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....  :(

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Don't understand debugging..???
« Reply #12 on: October 26, 2007, 08:41:01 am »
"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" .

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Don't understand debugging..???
« Reply #13 on: October 26, 2007, 08:43:57 am »
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!!
« Last Edit: October 26, 2007, 08:49:51 am by johne53 »

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Don't understand debugging..???
« Reply #14 on: October 26, 2007, 03:02:35 pm »
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
« Last Edit: October 26, 2007, 03:13:31 pm by jens »