Debugger on Linux depends on xterm for console apps

[cacb]

Hi,

I have just spent a couple of hours trying to solve a problem I thought was difficulties with debugging shared object files on Linux, i.e. how to set the proper g++ options. It turned out to be something completely different.

I have a tiny test application of console type that uses a class in a shared object. When I was debugging this under Linux Kubuntu 13.10 amd64 using self-compiled Code::Blocks svn 9492 (from Jens), I was able to step through lines in the main program, but unable to step into any function call from the shared object project, and I could not figure out why. All it said was 'no stack'. After checking, the g++ options seemed just fine. I tried debugging another application with the same debugger settings, and to my surprise debugging shared object files worked fine. The difference was that it worked only with a GUI application.

When running my console application in release mode, I noticed it said

Code

Executing: xterm -T filepicker_console -e /usr/bin/cb_console_runner

with an error about xterm

Then I realised what the problem was: the package xterm was not installed on this machine! (new machine).  After installing xterm, debugging shared object files from console application works just fine.   Maybe it is an idea to somehow let Code::Blocks depend on xterm, so that it is always installed and this problem does not happen to others?

[oBFusCATed]

Hm, interesting.
Can you post an example shared lib project that doesn't work?

I'm trying to debug a simple console application and I see this line:

Code

Can't launch console (xterm1 -T 'Program Console' -g 200x80 -bg gray -fg white -e sleep 80011778)

Do you see a similar line?

[cacb]

I don't see anything like that now (because I installed xterm), but if I do

Code

sudo apt-get remove xterm 

I get this when I try to debug a console app (the colour is as shown in Debugger tab.

Starting debugger: /usr/bin/gdb -nx -fullname  -quiet  -args /work/cpde3/proto/filepicker_console/.cmp/gcc/bin/Debug/filepicker_consoled
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.6.1-ubuntu
Can't launch console (xterm -T 'Program Console' -e sleep 80012526)
At /work/cpde3/proto/filepicker_console/main.cpp:96

reinstalling xterm solves that problem

Code

sudo apt-get install xterm 

In your case the debugger seems to be looking for "xterm1" but I have no idea what that is.

So my whole point was/is that it isn't the shared object code or project settings that caused my problems apparently, it was whether "xterm" was installed or not. It seems there may have been an exception thrown when xterm wasn't found, and that may have confused the debugger?

[oBFusCATed]

So my whole point was/is that it isn't the shared object code or project settings that caused my problems apparently, it was whether "xterm" was installed or not. It seems there may have been an exception thrown when xterm wasn't found, and that may have confused the debugger?

Debugging shared library works fine, if I don't have xterm1 as I've set it in the settings.
Please enable full debugger logging and post a log from a session where the debugging has failed.

[cacb]

Debugging shared library works fine, if I don't have xterm1 as I've set it in the settings.
Please enable full debugger logging and post a log from a session where the debugging has failed.

It wasn't a mirage. I struggled with it for several hours, even if I cannot reproduce it now. I ended up changing nothing in my project, but instead installing xterm, resolving the issue immediately. I know that shared library debugging usually works, I have done it many times. But in this case it didn't for some reason I cannot fully explain or reproduce.

My main message was that there is a run-time dependency of xterm, so installing Code::Blocks should naturally declare it as a dependency IMHO. Maybe there is a connection to the debugging problem, I honestly don't know.

This report is kind of similar, seems to support the exception theory
http://stackoverflow.com/questions/3475057/gdb-gives-no-stack-on-a-simple-stdstring-uncaught-exception

[oBFusCATed]

My main message was that there is a run-time dependency of xterm, so installing Code::Blocks should naturally declare it as a dependency IMHO. Maybe there is a connection to the debugging problem, I honestly don't know.

This is up to the packages to decide if they want to make it a dependency or not.
You're free to change the terminal to whatever you like it.

[Jenna]

As the user can decide which terminal to use, xterm is not a dependency in our control-file, "just" a recommendation.
I never use xterm and forcing a user to install something he do not need and do not want is not correct in my opinion.
A user would not be able to remove xterm without removing C::B also.

But the ubuntu-maintainers zuse their own control-file (at least they did in the past), so it might be different there.