Hi Anshul, Typically, the Original Report section is at the end of template, as a kind of reference.
Regarding the impact, I think you should probably go deeper than just saying it's #2 on errors.u.c. Why does that matter, what does that mean, what is the impact on the users or the distro? Why do we need to fix it? Also, please differentiate impact of the bug and planned fix for it :) The test plan should be more precise. "This crash can be reproduced by testing with a fake pid or killing a pid being tracked by apport" -> I'm an apport developer and I have no idea how to translate that into an actionable test plan. Also, while looking into this, I'm really wondering what I was thinking when I merged the "fix". This is really superficial, there's an underlying issue here: the /proc/$pid should really still be available at that point. AFAIK the only way to get the kernel to reap the crashed process before the core dump handler exits is to SIGKILL the zombie process, which might or might not happen too often. And then when one looks at the problem reports, one can see that the crashes started occurring on 2025-05-29, which is right when the security release was uploaded, sooooo... Something fishy is going on here... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2112466 Title: /usr/share/apport/apport:FileNotFoundError:/usr/share/apport/apport@600:get_pid_info on /proc/<pid> To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2112466/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
