Re: [Crash-utility] Re: crash enhancements proposal

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.