[Crash-utility] Re: crash enhancements proposal

[Kurtis D. Rader]

On Fri, 2006-05-05 16:20:27, Michael Holzheu wrote:
> I also always thought that it is not necessary to debug userspace stuff in
> crash dumps. Some weeks ago, ...
> 
> There they used the lcrash core command to extract the elf cores for all
> the userspace programs. At least it was possible to get the userspace
> stackbacktraces ...
> 
> So I think for very complex installations, there are cases, where it makes
> sense to just snapshot the whole system with a crash dump.
> 
> But I still think, it is best to just add an elf core command to crash and
> do the rest of user space debugging with gdb...

I agree with Michael. But I would point out that as someone who has been
doing UNIX kernel crash dump analysis for over fifteen years I can count
the number of times I've really needed the ability to extract the user
state of processes using both hands and feet. So this is definitely
worthwhile (especially if it can be easily implemented), but is low
priority in comparison to some of the other enhancements that have been
proposed.

Among the high priority needs are:

1) Cross architecture support. It is really painful for me to have to find
a ppc64 or s390x system with enough dasd and other resources to perform
an analysis. Given that most of tthe problems I look at do not involve
architecture specific issues it would be really useful if I could analyze
ppc64 and s390(x) dumps on a x86 or x86_64 system.

2) Scripting support. I'd prefer to see a commonly used scripting language
such as perl or python be integrated rather than something like SIAL be
invented. There is a project named "Alicia" that is working to integrate
perl with crash. But I haven't had time to play with it so I can't say how
well it works.

3) Making as much of the current crash initialization optional as possible
so that we have a hope of getting useful info (e.g., dmesg buffer) out of
the dump.

All of the other proposals have merit but are nowhere near as important
as the above. Also, in some cases it isn't going to be possible to fully
implement the proposed functionality. For example, you can't always display
the arguments to a function thanks to the new "fastcall" attribute which
causes arguments to be passed via registers. So tasks like stack analysis
are always going to require human intelligence.

-- 
Kurtis D. Rader, Level 3 Linux Support
ABC Service Center, Linux Change Team
T/L 775-3714, DID +1 503-578-3714