Date: Fri, 12 Jan 2001 15:55:11 +0100 From: Xavier Galleri <xgalleri@enition.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis Message-ID: <3A5F1ACF.6020909@enition.com> References: <Pine.BSF.4.21.0101121619441.320-100000@portal.none.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--------------000202050404040402080905
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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]
>
>
>
>
--------------000202050404040402080905
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html><head></head><body>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>
</body></html>
--------------000202050404040402080905--
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?3A5F1ACF.6020909>