Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Nov 2003 11:30:10 +1030
From:      Greg 'groggy' Lehey <grog@FreeBSD.org>
To:        Kent Kuriyama <kuriyama@newhost.cpf.navy.mil>
Cc:        questions@FreeBSD.org
Subject:   Re: Questions regarding use of 'gdb -k'
Message-ID:  <20031126010009.GT82843@wantadilla.lemis.com>
In-Reply-To: <200311240426.hAO4QcU5041986@newhost.cpf.navy.mil>
References:  <20031124031246.GW82843@wantadilla.lemis.com> <200311240426.hAO4QcU5041986@newhost.cpf.navy.mil>

next in thread | previous in thread | raw e-mail | index | archive | help

--sFDE4zCwgxz4NHeP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sunday, 23 November 2003 at 18:26:38 -1000, Kent Kuriyama wrote:
>> On Sunday, 23 November 2003 at 17:02:09 -1000, Kent Kuriyama wrote:
>>> I am having difficulty in using 'gdb -k' to track down a kernel panic.  I
>>> have built a version of the kernel with the debugging symbols.  After
>>> the crash I use the 'gdb -k' command but get the following output:
>>> ....
>>> IdlePTD at phsyical address 0x00000000
>>> initial pcb at physical address 0x0048cee0
>>>
>>> cannot read proc at 0
>>> (kgdb) where
>>> #0  0x0 in ?? ()
>>> (kgdb) exit
>>> Undefined command: "exit".  Try "help".
>>> (kgdb) chinmon1#
>>> ------------------
>>>
>>> Can you tell me what I am doing wrong?  Thanks.
>>
>> Unfortunately, this looks like you have a corrupted dump.  What you've
>> done (with the exception of "exit") is correct.  You might find it
>> better to use serial debugging if this is repeatable.
>
> Thanks.  Regarding the suspected corrupt dump file.  In the syslog I can
> see the dump file being created (actually 'vmcore') and there are no
> error messages.  Are you saying that the corruption occurs during
> the writing of the file or is the data resident in memory corrupt?

I suspect that the problem is that the contents of memory are so
scrambled that you can't do much with them.  I get this kind of
problem from time to time.  The whole purpose of having a dump is to
find out what went wrong on the system.  If it goes too far wrong,
there's nothing much left to see.

You could try debugging over a serial link.

> I suspect that something is wrong with the hardware on this box.  We
> moved the hard drive from one motherboard to another but the problem
> remains.  This leaves the hard drive as suspect but there are no
> syslog messages to indicate a drive problem.

You won't get syslog messages when the system crashes.  You could look
in msgbuf and see if there's any clue there:

# msgbuf: print msgbuf.  Can take forever.
define msgbuf
printf "%s", msgbufp->msg_ptr
end
document msgbuf
Print the system message buffer (dmesg).  This can take a long time due to the time it takes to transmit the data across a serial line.
end

Greg
--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply or reply to the original recipients.
For more information, see http://www.lemis.com/questions.html
See complete headers for address and phone numbers.

--sFDE4zCwgxz4NHeP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE/w/sZIubykFB6QiMRAhDfAKCF4PLdVu95E1UXTQfumm7EhhxwVwCgtHJi
y7pkLJ0hP8gLcKcphnIOJk0=
=UPh3
-----END PGP SIGNATURE-----

--sFDE4zCwgxz4NHeP--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031126010009.GT82843>