debugging on linux: strange symbols, files open twice, "nothing to be done"

[CuteAlien]

I noticed a few troubles when debugging on linux:

1. When I hit successive shortcut keys for debugging fast, then that does not execute the action but instead it inserts strange symbols into my code. Like Ś for F7. So I must always be careful to step only very slow.

2. The debugger always opens files which are already open once more. So if I have for example src/main.cpp open, set a breakpoint and start debugging then the debugger will open main.cpp (without src/ in the name) and stop there at the breakpoint (the breakpoint symbol will not be shown in this view - only in the other one).

3. When I stop a build and then go on "start debugging" I only get told "nothing to be done" and the debugger does neither start nor try to build. I have to change a sourcefile to get it working again.

I would be glad on any hints how to avoid those problems.

I'm using 8.02 with Build: Mar 17 2008, 00:38:40 - wx2.8.7 (Linux, unicode)

[Jenna]

Is your project in a directory that is a symbolic link to another ?

If yes read this post and my solution for it.

That can cause the double open files and maybe also that C::B does not recognize the changing of the file-stamp.

I'm not sure if the other problem is fixed in trunk (it happened to me from time to time, but test today worked without error, even if I kept the F7 key pressed).
You may want to try a more recent nightly.

[CuteAlien]

Yes I am using relative links, I should have mentioned that. Using mount instead of ln is certainly an interesting solution, I'd never had thought of that :-) But opening the project with the absolute path also does seem to work.

I might try a newer nightly, but can't do that right now. Guess I will just have to be careful for a while when debugging.

Thanks for your help.

edit: I switched to mounting by now, as I still had sometimes problems with the path. That has solved it now.

[CuteAlien]

I just tried a current nightly build (from your app sources) and the problem with F7 is indeed fixed :-)

Still some debugging troubles left unfortunately, like sometimes the application suddenly continues running while I'm still in the debugger (it's not multithreaded). And I'm rather certain I don't accidently press strg+F7. Also I haven't yet found out how to display wchar_t's.

But having those strange characters gone is already a big improvement!

[CuteAlien]

Another debugging problem :-(

The debugger can often not find local variables. I just get "No locals" in the Watches view or "no symbol X in current context" when trying to use mouse-over. Function Arguments including this object are available.  Any ideas?

[mandrav]

The debugger can often not find local variables. I just get "No locals" in the Watches view or "no symbol X in current context" when trying to use mouse-over. Function Arguments including this object are available.  Any ideas?

Do you have the debugger's debug log enabled?  If not, enable it (Settings->Compiler&Debugger->Debugger->Display debugger's log) and have a look at it next time this problem happens again. It would hopefully tell us if it's a C::B problem (e.g. parsing) or not.

[Jenna]

Another debugging problem :-(

The debugger can often not find local variables. I just get "No locals" in the Watches view or "no symbol X in current context" when trying to use mouse-over. Function Arguments including this object are available.  Any ideas?

This happens for me in (some ?) constructors.

Here is an article that is somewhat related to this problem: http://vladimir_prus.blogspot.com/2007/11/breakpoints-in-constructors.html.
With newer versions of gdb at least breakpoints in constructors work, but the problem with sometimes not showing locals is not (yet) resolved afaik.

[mandrav]

This happens for me in (some ?) constructors.

Yes, this does happen in ctors. But I don't complain; I feel blessed that breakpoints are even working in ctors now (in earlier gdb versions this didn't even work)

[CuteAlien]

Thanks again - that was the reason. I'm using some rather unusual long constructors in some testclasses, so I didn't notice those breakpoints where in a constructor. And I suppose this might maybe also be related to the problem when my application suddenly continues running. I think that also happened mostly after stepping into library code after hitting a breakpoint in a constructor. But I will keep an eye open for this.

Do you have any hints for me how to display arrays of wchar_t's as easy readable strings?

[new_user]

I am also seeing the same exact problem as CuteAlien in that the debugger can often not find local variables.  I also get "No locals" in the Watches view or "no symbol X in current context".

I am developing in C++ also, but I am not using objects (i.e. structural C++).  I am seeing these problems in just straight C functions.

I enabled the debugger's debug log and stepped through a couple of my functions and unfortunately it doesn't say there is any kind of a problem or error.   It just reiterates what is in the watch window.

One of my super simple functions-

int getRandomNum(int MaxNum)
{
   srand((unsigned)time(0));
   int randomNum = (rand()%MaxNum)+1;
   return randomNum;
}

has a watch window of:
Local variables
    No locals.
Function Arguments
    MaxNum = 1

and a Debugger (debug) Log of:
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
MaxNum = 1
>>>>>>cb_gdb:

I am using Code::blocks on Ubuntu 8.04 (Hardy).  It is version SVN 5195 Build: Aug 27 2008, 20:01:05 - wx2.8.8 (Linux, unicode).  I also have all compile optimizations turned off.

Thanks,

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

Maybe some thread-usage in the debugger or c::b itself?

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;
}

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>}

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.

[mandrav]

Right, this seems to be some kind of gcc/gdb bug.
This bug can be circumvented by removing the "virtual" keyword from the TestDebugger class' ancestors list

Code

class TestDebugger : public foo::Base1 ,public Base2

[CuteAlien]

Right, this seems to be some kind of gcc/gdb bug.
This bug can be circumvented by removing the "virtual" keyword from the TestDebugger class' ancestors list

Code

class TestDebugger : public foo::Base1 ,public Base2

That would work in my reduced test-case... but the real classes are derived from a class doing the reference-counting so that would introduce diamond inheritance problems :-(

Edit: I'll report it to the gdb people.

[Jenna]

Have you tried to use a pointer ?

Code

TestDebugger* iAmTheBug;

That works for me in the test-case.

[CuteAlien]

Have you tried to use a pointer ?

Thanks, nice workaround :-) That way I can actually debug it.

[mandrav]

... but the real classes are derived from a class doing the reference-counting so that would introduce diamond inheritance problems :-(

(emphasis added)

Which is why you shouldn't create such objects on the stack but only on the heap...
So, Jens is right (again) :

Have you tried to use a pointer ?

[CuteAlien]

Which is why you shouldn't create such objects on the stack but only on the heap...
So, Jens is right (again) :

Yeah, yeah, but sometimes you want to use classes in different contexts and except for debugging that would have worked. In that case it was a context specifically created for debugging, so every class needed was just in the function *sigh*.

Anyway, I could debug now, but while doing that I found out that I was too early when I announced that the problem with the strange symbols that get inserted sometimes in the sourcecode (mentioned at the start of thread) has been fixed with the newer nightly build I'm using. It certainly got a lot better, but I think it's somehow related to the speed of the debugger. When I stepped deeper and deeper into a library the stepping started to take more and  more time. And as soon as that happened I got the strange characters back when I pressed on stepping before the debugger was finished with it's current step. So that might also be something worth looking into.