I have some trouble when running gdb in a docker image and I am not sure what is causing the problems since I am a complete newbie when it comes to gdb and docker.
Background
I am trying to write a c++ program for the Lego EV3 which runs on ev3dev. In order to compile it, I have set up docker with the ev3dev image on my Windows machine and am able to successfully build inside that image, transfer the binary to the EV3 and execute it there. This all works well until I need to start (remote) debugging. My plan is to start a gdbserver on the EV3 with the program and the open a gdb session inside the docker container in my Windows machine and connect to the EV3 gdbserver. After I have fixed the first error when remote debugging - I needed to use gdb-multiarch on my Windows machine - I have encountered more problems which I don't really find a solution too.
Problem
When running gdb directly on my Windows machine inside the docker container (or when connecting to the gdbserver from docker using gdb-multiarch) I always get the following output after starting the program with run:
(gdb) run
Starting program: /src/ev3/build/src/EV3_main
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Warning:
Cannot insert breakpoint -1.
Cannot access memory at address 0x4f58
and when using next or step I get:
(gdb) next
Cannot find bounds of current function
Since I couldn't really find any solution online, I would really appreciate any help!
Thanks in advance!
I always get the following output after starting the program with run
This error usually means that the dynamic loader in your docker container has been fully stripped. It's a packaging mistake by the creator of that container.
If you are not using dlopen(), this isn't a big problem.
(gdb) next
Don't do that: you are not stopped in a location where GDB knows where the next line is. Do continue instead.
Related
I'm trying to display a basic Tauri app GUI running in a Docker container but connected to the host's X11 server through a unix socket. But I get the following warning and error when running npm run tauri dev:
(WebKitWebProcess:6009): Gdk-ERROR **: 00:17:37.147: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 258 error_code 2 request_code 152 (GLX) minor_code 34)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
I get opened a GUI window on the host but it's blank (but should contain some text / HTML markup).
As I am able to get Firefox and Gedit running from within the container but not the gnome-terminal, I think it's some permissions issue or there is some missing package to get the Webkit based GUI window connecting to my host's X server.
$DISPLAY and /tmp/.X11-unix are set properly. On the host I set xhost +
The container is running as node user. Cargo is installed in /home/node/.cargo/bin. /home/node is owned by root:node with 775 permissions on folders and 664 on files (+x on executable scripts).
I'm just getting started with Rust and Tauri and also not a big expert on X server and Docker networking.
Any ideas how to get it work?
I ended up using Qemu + Virt-Manager instead of docker. For the starters I've used an Ubuntu template as the clipboard sharing works out of the box with my host running on Ubuntu as well. Sound sharing and video playback works out of the box, too. And if I should get in the situation where I would need a separate VM for each app, then I would use my minimalist Arch template to spin up the VM's - the size should be pretty close to that of a docker container.
Edit:
LXC/LXD and Podman might be even better alternatives, I have been told.
I am using pycharm professional 2021.3.1 and ubuntu 18.04
I can attach to any process running directly on the host
However if the process is running inside a container (no matter what host privileges' I gave it)
I cannot attach. I get the following error
"Connection to python debugger failed Accept timeout'
I Tried on another computer and got the same results
Is this a known issue? Are there any work arounds? Except for using remote debugger (which requires adding extra code to the production code)
I found a way, it is not documented (as far as I can tell) but since it is for debugging only I will continue with it
Pycharm Professional set the IDE like you would for remote debug server
https://www.jetbrains.com/help/pycharm/remote-debugging-with-product.html#remote-debug-config
In the docker file of the containers that you wish to debug always install:
gdb
pydevd-pycharm
After the container and the process is up go into the container and run
"python3 /usr/local/pydevd_attach_to_process/attach_pydevd.py --port port_set_in_pycharm --pid pid_of_process_to_debug_in_container_id --host ip_of_the_host_running_the_pycharm"
the following is the same command pycharm uses when you do attach to process
now you can put breakpoints and debug normally
Advantage of this solution in contrast to remote debug defined in the pycharm documentation is that we do not have to add code to the production code
I'm getting this error whenever I try to run my project (with docker-compose) and cannot find any solution. I'm really hoping I've just been doing something dumb, so here goes...
I created a simple ASP.NET Core Web App (to test this out as I was having a problem on my "real" project.)
.Net Core 3.1
Visual Studio 16.11.3
Docker Desktop ver 4.0.1 (Docker Engine: 20.10.8)
Scenarios below were tried on both WSL2 and Hyper-V.
Docker itself is running fine, I can use containers no problem.
When I create the project with Docker support, I can run it fine (it creates the container, I can debug, etc)
If I add a docker-compose setup, however, I get the following error popup when I try run my project (from VS)
The only thing I can see in the output window (debug) is this:
The program '' has exited with code -1 (0xffffffff).
To be clear, the build was successful, the container is running in docker, etc.
After much effort, I found a way to get more information by running the following in the VS Command window:
DebugAdapterHost.Logging /On /OutputWindow
I now can see some more detail (in Output - Debug Adapter Host Log) but don't know how to solve it.
The most relevant message (afaik) is
1> ERROR: Debug adapter error output: /bin/sh: 1: /remote_debugger/vsdbg: not found
but here is the full output:
So I'm pretty stumped. I've uninstalled and reinstalled docker countless times, tried every imaginable setting, ensured everything is running with admin privileges, and so on.
In case it helps, here is my debug output from the same run (note how it says vsdbg is found)
Does anybody know what else I can try, or how to get more insight into this?
I have a docker image with a medical data analysis app installed in it. The app works from both gui and console. Normally, in my linux, I run the app from the terminal as
./dsi_studio --action=trk ...
and it works quite smoothly. If you click on this app, it'll try to open a GUI. While I'm trying to use this inside the docker image, it tries to connect to the display in any case (even if I run as shown in the terminal). And, of course, since I didn't do any setup for showing GUI from docker, I get the following error, stating that it couldn't find a display to connect.
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
I don't know why the app is trying to open a display while running in terminal, because it doesn't open a GUI in my linux. I just want to suppress this warning somehow, as if there is a fake display. I don't want to connect my display to docker image, because this image is going to run in batch in an HPC.
So, How can I do this?
You should probably export the DISPLAY environment variable to point to your linux terminal.
Just to test, run
xhost +
in your linux terminal and add
-e DISPLAY=:0.0
to your docker command line
My Python project is very windows-centric, we want the benefits of containers but we can't give up Windows just yet.
I'd like to be able to use the Dockerized remote python interpreter feature that comes with IntelliJ. This works flawlessly with Python running on a standard Linux container, but appears to work not at all for Python running on a Windows container.
I've built a new image based on a standard Microsoft Server core image. I've installed Miniconda, bootstrapped a Python environment and verified that I can start an interactive Python session from the command prompt.
Whenever I try to set this up I get an error message: "Can't retrieve image ID from build stream". This occurs at the moment when IntelliJ would have normally detected the python interpreter and it's installed libraries.
I also tried giving the full path for the interpreter: c:\miniconda\envs\htp\python.exe
I've never seen any mention that this works in the documentation, but nor have I seen any mention that it does not work. I totally accept that Windows Containers are an oddity, so it's entirely possible that IntelliJ's remote-Python feature was never tested on Python running in Windows containers.
So, has anybody got this feature working with Python running on a Windows container yet? Is there any reason to believe that it does or does not work?
Regrettably, it is not supported yet. Please vote for the feature request https://youtrack.jetbrains.com/issue/PY-45222 in order to increase its priority.