Date: Mon, 15 Jan 2001 16:32:44 +0100 From: Xavier Galleri <xgalleri@wanadoo.fr> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis Message-ID: <3A63181C.9020108@wanadoo.fr> 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
[-- Attachment #1 --]
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]
>>
>>
>>
>>
>
[-- Attachment #2 --]
<html><head></head><body><br>
Hi everybody,<br>
<br>
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
?<br>
<br>
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 ?<br>
<br>
Regards<br>
<br>
Xavier Galleri wrote:<br>
<blockquote type="cite" cite="mid:3A5F1ACF.6020909@enition.com">Thank you for your answer,<br>
<br>
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 ?<br>
<br>
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 ?<br>
<br>
Regards,<br>
<br>
Xavier<br>
<br>
diman wrote:<br>
<blockquote type="cite" cite="mid:Pine.BSF.4.21.0101121619441.320-100000@portal.none.ua"><pre wrap=""><br>On Fri, 12 Jan 2001, Xavier Galleri wrote:<br><br></pre><blockquote type="cite"><pre wrap="">OK, let's make it a bit clearer !<br></pre></blockquote><pre wrap=""><!---->....<br>[skiped]<br></pre><blockquote type="cite"><pre wrap="">Now, if you've read my first mail, I was actually asking for help onhow <br>to dump the stack of an interrupted process with GDB when the <br>kernelcrash occurs in the context of an isr. Actually, I would like to <br>know how I could dump the stack of *any* process at the time of the <br>crash. This way, I would be able to see where my user-land daemon was <br>lying in the kernel when the interrupt occurs.<br></pre></blockquote><pre wrap=""><!----><br><br>To dump stack of *any* (all) process you may write a little kld <br>wich will:<br><br>1) go through a process list,<br>2) get tf_eip, tf_esp, tf_ebp of a process<br>3) get p->p_vmspace <br!
>4) read process stack frames and all you need by manually<br> written routine based on procfs_rwmem and old good 'pread'<br> (which dosn't work now)<br><br>Another way is to go through proc list and coredump all the<br>processes for future manual analisys.<br><br>I like such way. <br><br>Can anybody point me to some difficults wich can appear while<br>implementing this?<br><br></pre><pre wrap=""><!---->[skiped]<br><br><br><br><br></pre></blockquote>
<br>
</blockquote>
<br>
</body></html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A63181C.9020108>