Bug#1141286: binNMU of gdb breaks procdump autopkgtest on i386

Edmund Lodewijks <[email protected]>
Newsgroups gmane.linux.debian.devel.bugs.rc
Message-ID <dcdba4ef-e411-4495-984a-58972d2c011e__19532.3223642603$1786624635$gmane$org@proteamail.com>
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._
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.