User forums > Help
debugging on linux: strange symbols, files open twice, "nothing to be done"
CuteAlien:
I also found out that the problem when my application just continues running doesn't seem to be related to constructors. I get that sometimes even when setting a breakpoint in the first line in main. The breakpoint gets activated (means - the files get opened and the cursor is set to that place), but the application does just not stop (and I also no debugger menu option except "stop debugger" is active - and that one does not work).
That's my debugging output for a breakpoint set in the first line of main :
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:
> cd ..
>>>>>>cb_gdb:
> directory /mnt/hdb5/virtascend/code/lib/freetype/freetype-2.3.5/builds/CodeBlocks/
>>>>>>cb_gdb:
> directory /mnt/hdb5/virtascend/code/lib/freetype/freetype-2.3.5/
>>>>>>cb_gdb:
> directory /mnt/hdb5/virtascend/code/lib/irrlicht/source/Irrlicht/
>>>>>>cb_gdb:
> directory /mnt/hdb5/virtascend/code/lib/irrlicht/
>>>>>>cb_gdb:
> directory ..
>>>>>>cb_gdb:
> directory ../src
>>>>>>cb_gdb:
> directory /mnt/hdb5/virtascend/code/uitool/CodeBlocks/
>>>>>>cb_gdb:
> directory /mnt/hdb5/virtascend/code/
>>>>>>cb_gdb:
> break "/mnt/hdb5/virtascend/code/uitool/src/main.cpp:268"
PS result: ? 27837 ps x -o tty,pid,command
PS result: pts/3 27835 sleep 101351
TTY is[/dev/pts/3]
GetConsoleTTY[/dev/pts/3]ConsolePid[27834]
Queued:[tty /dev/pts/3]
Breakpoint 1 at 0x80a7f37: file /mnt/hdb5/virtascend/code/uitool/src/main.cpp, line 268.
>>>>>>cb_gdb:
> tty /dev/pts/3
>>>>>>cb_gdb:
> run
Breakpoint 1, main (argc=1, argv=0xbfaf45b4) at /mnt/hdb5/virtascend/code/uitool/src/main.cpp:268
/mnt/hdb5/virtascend/code/uitool/src/main.cpp:268:8617:beg:0x80a7f37
>>>>>>cb_gdb:
> info locals
There was bug in the code and it did lead to a crash in the application rather soon, but not in the first line. When I just tried running it without breakpoint it also tolded me about some exception but didn't stop there, but simpy quit. When I tried if a few times I suddenly got around 80 messageboxes telling me about "signal raised" (probably because it didn't stop debugging when sending the message and the mainloop just raised that error all the time). Then c::b crashed. It behaved like the debugger would stop a wrong thread and another thread runs amok in background - but it's not a multithreaded application, so that doesn't really make sense. Maybe some thread-usage in the debugger or c::b itself?
I can reproduce that currently on each run... so if you want me to test something, I can probably do so.
mandrav:
--- Quote ---Maybe some thread-usage in the debugger or c::b itself?
--- End quote ---
I don't know about gdb but C::B uses no threads for debugging.
That's a strange problem indeed. I could attribute it entirely to gdb (the log you posted looks fine), except for the multiple message boxes. For that we must be missing something.
Anyway, the ideal help you could offer is help me reproduce it on my machine. But I guess this only happens on just one of your programs so that would be hard to do too.
Try that, maybe we can get a clue:
Do not set any breakpoints and start the debugging session with "step into" (Shift-F7). This will jump to the very first line of code, even before 'main'. Now click on "Debug->Send custom command" and type "break main". Then hit "Continue" (Ctrl-F7) and see if this time the breakpoint works. If it does, check the debug log for differences compared to the one you posted here.
CuteAlien:
"Step into" also did just run through the application. But I reduced it now to the absolute minimum needed to reproduce the problem here:
--- Code: ---namespace foo
{
class Base1
{
public:
virtual ~Base1() {}
};
};
class Base2
{
};
class TestDebugger : public foo::Base1 ,public virtual Base2
{
};
int main(int argc, char *argv[])
{
int hereBreakpoint = 1;
TestDebugger iAmTheBug;
return 0;
}
--- End code ---
As soon as iAmTheBug is outcommented it will stop at breakpoints. If it's like in the code above it will just run through and quit the application.
I hope it's reproducable on other systems.
mandrav:
Nice, I can reproduce this which means I can have a look at what's wrong :).
Jenna:
Your example works for me on w2k, but "info locals" in "Debugger(debug)" gives:
--- Code: ---> info locals
hereBreakpoint = 4199414
iAmTheBug = {<foo::Base1> = {_vptr$Base1 = 0x401370}, <Base2> = <invalid address>, <No data fields>}
--- End code ---
On linux it ends immediately, and if I use gdb from commandline, I can set the bp and stop there, but "info locals" leads to a segfault.
So it might be a gcc/gdb problem and not a C::B problem.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version