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:
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
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....
#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!!
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:
#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:
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:
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
@Jens,
Can you try this patch. If I remember correctly, it fixed that bug. :)
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);
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:-
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....
@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.
--- /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)
{
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 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 ...
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?
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