Maneesh Soni <maneesh@xxxxxxxxxx> 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@xxxxxxxxxx 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
