Castor , thanks to reply. I also donot have enough resource. :)
and also same thing is swapout case is not significant issue for this enhancement in our system , because most of our applications call mlock or shmctl(.. SHM_LOCK) . (it probably is better to put this item in TODO list.) OK, I'll try to dump latest kernel and elfdump some processes. and do some cleanup. if done , I'll post it on this ML. ---- Seigo Iguchi From: "Castor Fu" <[email protected]> Subject: RE: [Crash-utility] user-space enhancements Date: Fri, 12 Dec 2008 15:55:44 -0800 > I don't really have resources to devote to merging my code, but I can > probably send you what I have. Our system usually doesn't > have the critical processes swapped at all, so it's not something > that I've worried about. > > Seigo, it sounds like you're situation is similar to mine. As I said > before, I can look into making sure it's ok to release our code. > > -castor > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of S.Iguchi > Sent: Monday, December 08, 2008 1:26 AM > To: [email protected] > Cc: Castor Fu > Subject: Re: [Crash-utility] user-space enhancements > > > Hi, > > > We ported it to crash as a loadable extension, but only did the i386 > > stuff. > > > > If there's enough interest we could see about liberating our internal > > code. > > Cool. > > I also have such crash extention module works only on x86-64... > and tested only with 2.6.10 and 2.6.20 . > > # crash -s vmlinux-2.6.20-1.2320.fc5 /mnt/fc5/var/crash/2008-01-28-18 > \:17/vmcore > : > crash> extend elfcoredump.so > elfcoredump.so: shared object loaded > crash> elfdump 1 > elfdump: write elfcore.1 done... > crash> > # gdb /sbin/init elfcore.1 > : > > To enable dump shmem, add -s option . > > But unfortunately , the module is coredump_filter unaware. > and has a lots TBD code . > > BTW, Oda-san mentioned page swapout case on another thread , > in that case , I decided simply seek to next page (same as ZERO page > case). > sigh... i know its incorrect. > > I think this module contains incomplete functionality , but > should be maintained in crash community . > > Castor, how about merge mine and your i386 module ? > > Thanks. > > Seigo Iguchi. > > > From: "Castor Fu" <[email protected]> > Subject: RE: [Crash-utility] user-space enhancements > Date: Thu, 4 Dec 2008 14:06:29 -0800 > > > There was a group at IBM (Stefan Schlosser <[email protected]>) > > a few years ago which set up stuff to generate > > a elf corefile for a user space process for lcrash. > > > > We ported it to crash as a loadable extension, but only did the i386 > > stuff. > > > > If there's enough interest we could see about liberating our internal > > code. > > > > -castor > > > > > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Bradshaw, James > > Sent: Thursday, December 04, 2008 12:58 PM > > To: Discussion list for crash utility usage, maintenance and > development > > Subject: RE: [Crash-utility] user-space enhancements > > > > > > Right. To be able to examine user space, you'd have to build an elf > core > > > > file by processing the desired task structure in the kdump file, find > > all > > the user pages, etc.--essentially what elf_core_dump() does in a > running > > > > kernel. Then you could use gdb offline or the embedded gdb. > > > > I understand your desire not to burden crash with user space stuff, > > although the extensions facility seems to provide a mechanism for > > cleanly > > excluding such functionality from the standard configuration. Just a > > thought. > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Dave Anderson > > Sent: Thursday, December 04, 2008 3:25 PM > > To: Discussion list for crash utility usage, maintenance and > development > > Subject: Re: [Crash-utility] user-space enhancements > > > > > > ----- "James Bradshaw" <[email protected]> wrote: > > > > > One of the items in the bug list is the following: > > > > > > DESCRIPTION: > > > User space enhancements: > > > - show user space stack backtrace, if present in the dump file, > > > - ability to link user space namelist (debug object files), > > > > > > RESOLUTION STATUS: TBD > > > > > > Is anyone currently working on this? > > > > The items in the TODO list, with the exception of the first > > one about the "search" command, are all essentially "wish-list" > > items. They were originally requested to be put there by IBM > > several years ago when the http://people.redhat.com/anderson > > site was instantiated as the "upstream" source of the crash > > utility. > > > > The only item that I'm aware of that somebody is actually looking > > into is the one regarding "local variables", where I believe the > > guy looking into it is part of the IBM LTC in India. I don't > > expect much to come out of it, though, because for one thing > > it presumes that the crash utility's backtrace frame information > > is etched in stone -- and with the exception of ia64 which has > > unwind information actually built into the kernel -- the backtrace > > is essentially a "best-guess" operation. So trying to pull local > > arguments (or function arguments for that matter) from a > > dubious source doesn't make a whole lot of sense. > > > > As far as a user-space backtrace, I still think the way to go > > is to work on creating a core dump file of the requested task, > > and then use gdb externally on that core file, completely outside > > of the crash utility. Trying to overload the crash utility with > > a bunch of user-space stuff is something I don't have a lot of > > interest in. > > > > Dave > > > > > > > > > > > > -- > > Crash-utility mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > -- > > Crash-utility mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > This email and any attachments thereto may contain private, > confidential, and privileged material for the sole use of the intended > recipient. Any review, copying, or distribution of this email (or any > attachments) by others is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and > permanently delete the original and any copies of this email and any > attachments thereto. > > > > -- > > Crash-utility mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/crash-utility > > -- > Crash-utility mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/crash-utility > > > This email and any attachments thereto may contain private, confidential, and > privileged material for the sole use of the intended recipient. Any review, > copying, or distribution of this email (or any attachments) by others is > strictly prohibited. If you are not the intended recipient, please contact > the sender immediately and permanently delete the original and any copies of > this email and any attachments thereto. > > -- > Crash-utility mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
