Dear maintainer(s),

With a recent binNMU of gdb the autopkgtest of procdump fails in testing
when that autopkgtest is run on i386 with the new binary packages of gdb
from unstable. It passes when run with only packages from testing. In
tabular form:

                        pass            fail
gdb                    from testing    17.2-1 (binNMU)
procdump               from testing    2.2-4
all others             from testing    from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of gdb to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

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

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gdb

https://ci.debian.net/data/autopkgtest/testing/i386/p/procdump/72739897/log.gz

  38s TASK PID = 1814
  38s -rwxr-xr-x 1 root root 3487072 Mar 28  2025 /usr/bin/procdump
  38s PROCDUMP PID = 1818
  38s root        1818  0.0  0.0 238996  2840 ?        Dl   12:18   0:00
procdump -pgid 0 -n 1
  38s root        1820  0.0  0.0   6300  2384 ?        S    12:18   0:00
grep -i 1818
  48s Killing 1814
  48s Killing 1818
  48s ls: cannot access 'sh_time*': No such file or directory
  48s Cores dumped: 0
  48s Failed
  49s autopkgtest [12:18:23]: test run.sh

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.
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

Here is a follow-up to my previous email, with a merge request and one
clarification / correction.

One clarification / correction: I wrote that the test coredumps the
container
"instead of" the sleep it created. The correct test target is, of course,
also in the container, and therefore included.

Nothing needs to change in gdb or python3.14.

The binNMU is measurably slower at gcore on i386 (~1.57x, most likely
resulting
from heavier imports in python 3.14). This only mattered because the
test had no
margin: Even with the old gdb it was already using 8 of its 10 seconds once
the container held ~46 processes.

The proposed fix with MR:

This fix passes the pid directly; names the dump file so the expected result
is an exact path; and polls for it, instead of sleeping a fixed 10s
(hardcoded
in the current / old test).

https://salsa.debian.org/debian/procdump/-/merge_requests/1

(This MR is against the debian/unstable branch on Salsa)

I tested this:

Old / current test: With 60 idle processes present and pinned to one
CPU, the
old test passes 5/5 with gdb 17.2-1 and fails 5/5 with 17.2-1+b1.

New test: The new test passes 5/5 under both, in 1-2s. Happy to post fuller
measurements if anyone wants them.

All green on the Salsa CI.

`procdump` is orphaned (Debian QA Group, #1095431), but I see that
Gianfranco
Costamagna has been working on `procdump`, so I'd want to be in touch
with him
before submitting anything beyond the MR.

I hope this helps!

Kind regards,

     Edmund


_Triaging was done with the help of Claude - There was a lot to go
through and
to unpick. I hope this is okay. The verification of what it came up
with, plus the new
test are mine, for which I take responsibility._