On Thu, 2 Jul 2026 19:06:58 +0200 Paul Gevers <[email protected]> wrote:
Source: gdb, procdump
I looked into this a bit, and, at the end of this day, can only provide
some findings so far.
The issue seems to me to be in procdump (the Debian part), not in gdb.
It seems that the error is coming from the lack of a coredump that is
intended to fail the test several only several lines later:
https://sources.debian.org/src/procdump/2.2-4/debian/tests/run.sh#L28
From what I gather, the problem stems from the d/tests/run.sh script. I
don't think it is doing what it intends to do:
procdump derives a process group id with `ps -o pgid=` and passed it to
`procdump -pgid`. But inside the autopkgtest environment, every `pgrp`
seems to be `0` (see below).
In other words: Instead of dumping the one `sleep` it created, the test
coredumps the entire container.
From a run on i386:
[INFO]: Monitoring processes of PGID '0'
[INFO]: Starting monitor for process su (1)
[INFO]: Starting monitor for process sh (2)
[INFO]: Starting monitor for process tee (25)
[INFO]: Starting monitor for process sleep (32)
[INFO]: Starting monitor for process procdump (34)
[INFO]: Starting monitor for process ps (35)
[INFO]: Starting monitor for process grep (36)
...
Cores dumped: 3
The test sets a timeout of 10s, which might not be enough if the test
checks every process, rather than a targeted PID and coredump, depending
on the test server resources etc.
Unless I am mistaken, I think some changes to the test script would
solve this issue.
Good night!
Edmund
--
Edmund Lodewijks <[email protected]>
TZ: UTC+2 / GMT+2
