[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Panic: zalloc!
From: |
Jon Arney |
Subject: |
Panic: zalloc! |
Date: |
Thu, 28 Feb 2002 00:31:48 -0700 |
Hi there,
This is going to sound a little meandering, but I promise I'm going
somewhere with this.
For several days now I have been enduring a Hurd system which seems to
reboot on me every once in a while when I'm not watching. Through
plain dumb luck I happened to be in the room with the machine when
it happened (I was re-compiling glibc-2.2.5 natively). Two interesting
things happened.
1. The lower-most 'make' in the tree had no children but was not
'doing' anything. I interrupted it with
$ gdb `which make` <pid-which-i-forget>
It seemed to be 'stuck' in setuid(0) (didn't save the whole backtrace)
but the topmost was intr-msg:118 in something like
_hurd_intr_rpc_msg_...
2. In the middle of the 'gdb' session (while I'm dutifully
attempting to get details), my 'telnet' session locked up. I said to
my self "Self, this is not good".
Going to the physical console, I noticed a message 'panic: zalloc....'
and before I could copy it down, the box re-booted on me.
This brings me finally to the point!
Around line 171 of gnumach/kern/debug.c I found the following fragment
from the 'panic' function. Note the #else case and the argument to
the function 'halt_all_cpus'. I would like to recommend that the
argument be changed to '0' _OR_ that MACH_KDB be enabled by default
until such panics are not so prevelant, so that when one is not
physically present, one can get information on the panic. Hindsight
is 20:20 in that I realize I should have enabled the debugger.
Nonetheless, I think my recommendation stands.
#if MACH_KDB
Debugger("panic");
#else
halt_all_cpus (1);
#endif
Humbly yours,
Jon Arney
Software Engineer
jarney1@cox.net
------------------------------------------------------------------------
- Panic: zalloc!,
Jon Arney <=