Date: Mon, 15 Jan 2001 16:56:08 +0100 From: Xavier Galleri <xgalleri@enition.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis Message-ID: <3A631D98.7050101@enition.com> References: <Pine.BSF.4.21.0101121619441.320-100000@portal.none.ua> <3A5F1ACF.6020909@enition.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi everybody, My little problem does not seem to make anybody enthousiastic, at which point that I am wondering if there is any GDB user on kernel dump listening over there ... Maybe I am on the wrong mailing list ? Or should I look for further help somewhere else ? Or is it that my explanations were not clear enough ? I have found that issuing an 'info frame @ebp @eip' command could provide the beginning of a stack dump analysis. Now, I am trying to find out where is stored the stack frame of the current process when an interrupt occurs. Is there anybody who knows this ? Regards Xavier Galleri wrote: > Thank you for your answer, > > It's difficult to believe that nothing more intuitive and immediate > can be done to get the kernel stack of any process from a GDB session > on a kernel crash dump. Does it mean that this is something that > nobody ever need until now ? > > Also, is there a mean to ask GDB to dump the kernel stack of the > 'curproc' that has been interrupted at the time of kernel panic ? > > Regards, > > Xavier > > diman wrote: > >> >> On Fri, 12 Jan 2001, Xavier Galleri wrote: >> >>> OK, let's make it a bit clearer ! >> >> .... >> [skiped] >> >>> Now, if you've read my first mail, I was actually asking for help onhow >>> to dump the stack of an interrupted process with GDB when the >>> kernelcrash occurs in the context of an isr. Actually, I would like to >>> know how I could dump the stack of *any* process at the time of the >>> crash. This way, I would be able to see where my user-land daemon was >>> lying in the kernel when the interrupt occurs. >> >> >> >> To dump stack of *any* (all) process you may write a little kld >> wich will: >> >> 1) go through a process list, >> 2) get tf_eip, tf_esp, tf_ebp of a process >> 3) get p->p_vmspace >> 4) read process stack frames and all you need by manually >> written routine based on procfs_rwmem and old good 'pread' >> (which dosn't work now) >> >> Another way is to go through proc list and coredump all the >> processes for future manual analisys. >> >> I like such way. >> >> Can anybody point me to some difficults wich can appear while >> implementing this? >> >> [skiped] >> >> >> >> > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A631D98.7050101>