Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Debbuging a `-slim` image?

未關閉
  • 哪裡不對？
#903 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
25/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
docker, python
領域
devops, tooling

研究方向

未指定任何 repository 檔案或測試。首先比較 python:3.11-slim-bookworm 和 python:3.11-bookworm 映像的建置，然後重現 gdb attach 命令，並檢查可執行檔與除錯符號之間的不相符。完成的標準是確定 py-bt 是否能針對 slim 映像運作，並記錄一種可重現的除錯方法或限制。

由索引模型根據 Issue 內容生成。

描述

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 and python3-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

➡️ 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.
FROM python:3.11-bookworm

RUN --mount=type=cache,target=/var/cache/apt --mount=type=cache,target=/var/lib/apt \
    apt update -y && \
    apt install -y gdb

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.

docker run \
    --cap-add SYS_PTRACE \
    --pid container:15aab7ea5f57 \
    --privileged  \
    -ti \
    --entrypoint bash docker.io/library/mydebugpython

root@bb90d04f8722:/# gdb -q python --pid 1 -ex "py-bt"

Reading symbols from python...
Attaching to program: /usr/local/bin/python, process 1

warning: Build ID mismatch between current exec-file /usr/local/bin/python
and automatically determined exec-file /usr/local/bin/python3.11
exec-file-mismatch handling is currently "ask"

Load new symbol table from "/usr/local/bin/python3.11"? (y or n) y
Reading symbols from /usr/local/bin/python3.11...
Reading symbols from target:/usr/local/bin/../lib/libpython3.11.so.1.0...
(No debugging symbols found in target:/usr/local/bin/../lib/libpython3.11.so.1.0)
Reading symbols from target:/lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/82/ce4e6e4ef08fa58a3535f7437bd3e592db5ac0.debug...
Reading symbols from target:/lib/x86_64-linux-gnu/libm.so.6...
Reading symbols from /usr/lib/debug/.build-id/ea/87e1b3daf095cd53f1f99ab34a88827eccce80.debug...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/38/e7d4a67acf053c794b3b8094e6900b5163f37d.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__GI___clock_nanosleep (clock_id=1, flags=1, req=0x7ffd9d9ec458, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:71
71	../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory.
Traceback (most recent call first):
  (unable to read python frame information)    # <--------------   :(

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.

主要語言
Dockerfile
星號
2.8k
分支
1.1k
平均合併
3 天 1 小時
30 天內合併 PR
1

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

docker-library/python 的其他 Issue

查看 docker-library/python 的全部 Issue

相似的 Issue

更多 DevOps Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。