> On the other side, if some kind of corename patch makes it into
> the kernel and administrator chooses to put all core files e.g to
> /tmp/cores/core.<pid>, then some ucore program can poll on /tmp/cores
> and once it notices a new file created there, just spawn a debugger
> or whatever the user wants (not that I'd like to do it on my machines).
> But such thing should be implemented in userland, why to bloat the kernel.
Spawn a debugger on the core file?
Oh no, you missed the whole point of this idea. Such a hack would not
need to be in the kernel, and would be nearly useless anyway.
Goal: start a debugger on a live process, with all the process
relationships intact and file descriptors still open. The process
should be as intact as if you had attached a debugger yourself
right before the crash.
The general plan is to let users have this feature effective for all
processes, not just ones expected to crash. That means zero overhead
is a requirement. The OS must pass standards compliance tests with the
feature operating. Nothing can interfere with process relationships
or signal handling
There is a clear need for kernel support here.
Proposed implementation:
Provide debug info via a World-accessable character device.
On a per-UID basis, a crash monitor watches for trouble.
If something crashes:
1. dying process sleeps
2. message passed to crash monitor
3. crash monitor can say "dump /tmp/joe-1.core" or start ddd or ...
The crash monitor is totally the user's choice. It could have
debugging ability, but most versions would rely on a separate
debugger. It could look up the program in an RPM or DEB database,
then offer to email an accurate bug report. It could offer to
unpack or download source code for you. It could offer to hide
the bug for a moment so that you might be able to save your work.
BTW, I think the plain core name patch belongs in 2.2.xx while
the rest is obviously a big 2.3.xx project.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/