Maneesh Soni <maneesh(a)in.ibm.com> wrote on 05/05/2006 09:52:32 AM:
On Fri, May 05, 2006 at 09:34:39AM +0200, Michael Holzheu wrote:
> crash-utility-bounces(a)redhat.com wrote on 05/05/2006 09:06:55 AM:
> > > For lcrash (lkcdutils) we have a patch, which provides
> > > functionality to create an elf core dump out of a
> > > system crash dump. This core dump can
> > > then be processed with gdb. We already have code to
> > > include swap devices and files.
> > >
> > > Maybe that is also one option, which should be considered
> > > here.
> >
> > If I am not wrong you meant, that "lcrash" is able to show user
space
> stack
> > backtrace because the dump includes data from swap devices & files?
> > Just wondering if you have used "crash" in the same manner?
> >
>
> There exist a patch for an older version of lcrash which implements
> the following functionality:
>
> * read in swap files, when you start lcrash. Something like:
> >> lcrash System.map dump Kerntypes swap1 swap2 ....
> The swapfiles have to be saved of course at boot time
> after a system crash.
>
> * implement a core command in lcrash:
> >> core <process ID of process XY>
> This writes an elf core file for process XY to disk.
>
> After you have the core file, you can use gdb
> to analyze the userspace problem:
>
> gdb XY core
>
> Any more questions?
Thanks, I got it now. But IMHO this functionality more looks like part of
crash dumping mechanism than crash analysis tool. In anycase it
should be
useful.
You need the infrastructure of crash or lcrash in order to
analyze kernel datastructures to generate a core dump.
So it is the easiest way to implement it in a dump analysis
tool. If you have an idenpendent library, which provides
the funcitonality of accessing kernel data structures
in a dump, you could write of course a separate
userspace tool like crashdump2core or something like
that.
Michael