Open hterik opened 8 months ago
This is similar to one problem I am having, their image doesn't have any debug symbols so I decided to add it.
This is the issue we were discussing. https://github.com/docker-library/python/issues/807 I had to do this to have the debug images: https://github.com/Luiz-Monad/docker-python/commit/fe752b6410d1defc6e42400120f2605bf9d6f3e7#diff-b3c0fcf605d397bd3fce8ea61588d2c9da8b24a9fe6886b2e640d97914f1d01f
Here is how you're supposed to use it https://github.com/docker-library/python/pull/701
We are hitting a rare deadlock in production that can't be reproduced using debug images. Only way to debug it is to attach to the production image as the problem happens. Problem is that production are based on the
-slim
images.apt install gdb
andpython3-dbg
is not enough because the python running is built from source and not aligned with what is available in apt.I've tried to start the corresponding non-slim image but their binaries don't seem to align enough to make gdb happy:
Start python inside
-slim
image:arrow_right: My end goal is to run gdb
py-bt
on this process:docker run -ti python:3.11-slim-bookworm python3 -c "import time; time.sleep(1000)"
Inside this image there is no chance to debug at all due to missing gdb and debug symbols. This is expected.
Build a debugger image from the corresponding non
-slim
image.docker build -t mydebugpython .
Use the newly built debug image to attach into the first running container
Find the container id and use that to attach to the same pid-namespace.
So it seems like the difference of
slim
and non-slim
isn't only the presence of debug symbols or not, but also the binary is built differently? Is this possible to solve somehow? My knowledge of how python is built and how to operate gdb are only moderate.