Missing crash reports for long-running processes

[Matt Zimmerman]

My X server just crashed, but it didn't generate a crash report.  Reading
/var/log/apport.log, I see:

apport (pid 29843) Thu Aug 20 08:10:57 2009: called for pid 22667, signal 11
apport (pid 29843) Thu Aug 20 08:10:57 2009: Unhandled exception:
Traceback (most recent call last):
  File "/usr/share/apport/apport", line 244, in <module>
    info.add_proc_info(pid)
  File "/usr/lib/python2.6/dist-packages/apport/report.py", line 346, in add_proc_info
    assert os.path.exists(self['ExecutablePath'])
AssertionError
pid: 29843, uid: 0, gid: 0, euid: 0, egid: 0
environment: {}

My assumption is that this means the X server package had been upgraded
while it was running, and so the running copy of /usr/bin/Xorg was deleted.
This probably shouldn't trigger an AssertionError since it can happen during
normal system operation (but it is a fatal error nonetheless).

Because the running X server is generally not restarted when it is upgraded
(because this would destroy the user's session), this seems like a common
case for users running the development branch.  Unless they have quit their
session since the last X server upgrade, they will not get any crash
reports for the X server.

The same will be true for other long-running processes, like dhclient for
example.

Of course, this particular bug report would have been suppressed anyway, because the
package was out of date, and furthermore, according to the backtrace in the
log, my crash was a duplicate of
https://bugs.edge.launchpad.net/bugs/343528.

This got me thinking, though, about the general case here.  This type of
long-running process will generally *not* leave a crash report behind when
it crashes, unless it happens very early in its lifetime (before the next
package upgrade).  It seems like we may be missing out on the benefits of
apport in this case.

Is this worth fixing?  I could imagine some simple changes to save the
running Xorg binary for use by apport, if this would be useful.

-- 
 - mdz