GDB exited with code 127 - Arch Linux (Docke Image)

[claudio]

Hi,

i did install codelite 12.0 into an arch linux docker image and start the docker image from my centos7.

docker run -it -d --name MyCodelite -e DISPLAY -e XAUTHORITY=/tmp/.Xauthority -v /home/user/.Xauthority:/tmp/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix -v ~/dev:/root/dev myrepo:arch_base codelite

Codelite ist running up and GUI is shown.

I did create a small HelloWorld C++ Project - in ReleaseMode is running and output "Hello World" is shown.

#include <stdio.h>

int main(int argc, char **argv)
{
printf("hello world\n");
getchar();
return 0;
}

But running same in DebugMode i get the following error:
Debugger exited with the following error string:
"During startup program exited with code 127."

Breakpoint set in first Line is never reached.

I also did try "Quick Debug" and wondering that a terminal windows opens for just about a second, showing a message i cannot read in this time...but i think these are about the outputlines;
&"warning: GDB: Failed to set controlling terminal: Operation not permitted
Could not trace the inferior process Error
warning ptrace Operation not permitted

Because of this problem, i cannot debug....any ideas what could be wrong here?

Note what i did checked already:
echo $TERM shows: xterm
which xterm shows: /usr/sbin/xterm

Many thanks in advance for help hopefully:-)

Best Regards Claudio

[DavidGH]

Hi,

I've little experience with docker, and none with Arch; so I can't help with any problems related to those. However I can reassure you about the "warning: GDB: Failed to set controlling terminal: Operation not permitted" message. It always happens with CodeLite and at least 2 other IDEs, and doesn't matter at all (for details see here).

But running same in DebugMode

Did you make a separate debug configuration and build? Does it point to a HelloWorld binary that works if you run it in a terminal outside CodeLite?

Regards,

David

[claudio]

Thank you David.

I have two configurations, one for Release and one for Debug.

Yes, the Release and the Debug binary are builded and both running within a terminal.

I did the test as follow:

cd Release
/usr/bin/codelite_xterm './HelloWorld' '/bin/sh -f /usr/bin/codelite_exec LD_LIBRARY_PATH=/lib;/lib64 ./HelloWorld '
Output into a new opened Terminal Window: Hello World

cd ..
cd Debug
/usr/bin/codelite_xterm './HelloWorld' '/bin/sh -f /usr/bin/codelite_exec LD_LIBRARY_PATH=/lib;/lib64 ./HelloWorld '
Output into a new opened Terminal Window: Hello World

[DavidGH]

One thing I should have suggested in my first post: turn on 'Full Debugger Logging'. You can do that from Settings > GDB settings: Misc or, more easily, in the Output tab of the Debugger pane. Then try debugging your 'debug' build again; you will get a lot of output (99% irrelevant) and if you're lucky it might show the reason for the problem.

If that fails, the next thing to do is to try one of the template projects that CodeLite provides e.g. Console: Simple executable (g++). Add it to your current workspace or to a new one. It's code is almost the same as that of your current project, but maybe its settings are different.

If a debug build of that still fails to run, perhaps try installing and selecting a different terminal e.g. konsole or lxterminal.

Otherwise I'm afraid I've run out of ideas. Perhaps it's somehow a Docker issue...

[claudio]

I found this error in the full log: "Failed to start debugger: permission denied"

I found out with google that a linux policy does not allow user root working with gdb...therefore i did create a user developer (with pwd developer) and added the user developer to the groups users, log, wheel and uucp. I also edited /etc/sudoers and allowed users of group wheel sudo access without using a password.

I did start codelite and it is running now below this new user developer and not longer under the user root as before, but i am wondering because i get the same permission denied error again.....any idea why it is gdb not allowed to run called from codelite with current user developer?

[DavidGH]

Why are you running anything as root? Is it a Docker thing? Doesn't it supply a standard non-root user that you can su to?

When you successfully ran the program inside gdb in a terminal, which user did that?

[claudio]

I did find the problem, it is a docker issue related to my docker arch linux container:-(

I need to add the following to my docker run commandline:

--cap-add=SYS_PTRACE --security-opt seccomp=unconfined --security-opt apparmor=unconfined

Hint: only editing /etc/sysctl.d/10-ptrace.conf and adding "kernel.yama.ptrace_scope = 0" (without ") does not help, it should help only on non docker system.

Btw.: If debug dialog window cannot readed because it is shown less one second, open a shell (kontext on a project, than "Open Shell") and call gdb directly like this: gdb -q sleep -ex 'run 60'
Or try it direct with your image, change to your debug folder where your debug binary is then hit on the commandline:
gdb -q YOURBINARYNAME -ex 'run 60'

Many thanks for help!!