Mon 26 Dec 2005 10:44:53 PM UTC, original submission:
From http://bugs.debian.org/82600
From: Neal H Walfield <neal@cs.uml.edu>
To: -unavailable-
Subject: ranlib causes kernel panics
Date: Wed, 17 Jan 2001 00:29:33 -0500
Package: gnumach
Version: CVS Snapshots
When doing large builds, I have gotten a lot of kernel panics (gnumach).
They are (so far) caused without exception when ranlib is running. Just
now, I got a chance to see the console before it rebooted itself (and
as usual, trashed the partition). It said:
panic: zalloc
The only place I found this was in kern/zalloc.c.
libc0.2: 2.2-3
binutils: 2.10.0.27-0.cvs20001011.2
hurd: CVS Snapshots
From: Roland McGrath <roland@frob.com>
To: Neal H Walfield <neal@cs.uml.edu>, -unavailable-
Subject: Re: Bug #82600: ranlib causes kernel panics
Date: Wed, 17 Jan 2001 00:39:33 -0500 (EST)
That is a resource-shortage crash. If you got a stack trace of the crash
(e.g. use ddb if that still works), then we could see what kind of kernel
object it was allocating. It might be a general eat-all-memory bug, or it
might be a fast leak in some particular kind of kernel object (ports, etc).
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: -unavailable-
Subject: zalloc panic
Date: Mon, 29 Jan 2001 01:34:07 +0100
Hi,
we reproduced this by a simple self invoking script
# cat > /tmp/foo
#! /bin/sh
sh /tmp/foo
^D
# sh /tmp/foo
panic: zalloc4
(we changed the panic messages in kern/zalloc.c, zalloc4 is in line 486
(zget_space returns 0)).
Kernel Breakpoint trap, eip 0x10ccc8
Stopped at 0x10ccc7: int $3
trace
0x10ccc7 (1657bf)
>>>>> (unknown) (51) at 0x10d0300 <<<<<
0x10d03000 (Kernel General protection trap, eip 0x13fd60
Caught General protection (13)
Code = 0, pc = 13fd60
Marcus
From: Roland McGrath <roland@gnu.org>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>,
-unavailable-
Subject: Re: Bug #82600: zalloc panic
Date: Sun, 28 Jan 2001 20:12:19 -0500 (EST)
That location is inside the allocator, so just from the PC we don't know
what kind of thing is being allocated. We need to see backtrace from the
panic. If ddb works these days, you can use that and then put the PC
values through addr2line.
I just checked in a simple change to zalloc.c to make all those panic
messages include zone->zone_name, which will tell us what the kernel
object involved is.
You can also write a program using the <mach_debug/mach_debug.defs>
host_zone_info RPC to collect statistics on the zones and look for
balloons. But in your case it looks like it's so quick you wouldn't have
the chance. You might want to change the panics to print out zone
statistics when they panic.
From: Roland McGrath <roland@gnu.org>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>,
-unavailable-
Subject: Re: Bug #82600: zalloc panic
Date: Sun, 28 Jan 2001 20:22:12 -0500 (EST)
Oh, well, I just now actually looked at your script and realized that you
are running a fork bomb. Which is to say, the essence of that program is
the same as "while (fork () == 0) ;". Such a program always ends in a
pathological resource shortage. Unix has things like per-owner (uid)
resource limits on the number of processes that can prevent this (but won't
if you're root).
It is certainly the case that the kernel behaves poorly (i.e. panics a lot)
in all sorts of extreme resource shortage situations. That is not good,
but it would be tedious at best and perhaps really a lot of hard work to
make it better in Mach.
There are doubtless nonrobustnesses in the Hurd code as well when it comes
to resource shortages. It would a fine thing to find those and fix them.
But the kernel dies before those really get exposed.
Though not directly relevant to your report (since it runs as root), real
resource limits are also definitely a good thing to have. We really have
nothing meaningful in the Hurd; we don't even include resource limits in
the protocols for inheritance by exec and such. Many resource controls can
only actually be enforced by the kernel, because its interfaces give direct
access to kernel resources (vm_allocate, task_create, et al). Some such
controls might not be too hard to implement.
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Roland McGrath <roland@gnu.org>
Cc: -unavailable-
Subject: Re: Bug #82600: zalloc panic
Date: Mon, 29 Jan 2001 20:52:06 +0100
On Sun, Jan 28, 2001 at 08:22:12PM -0500, Roland McGrath wrote:
> Oh, well, I just now actually looked at your script and realized that you
> are running a fork bomb.
Yep, that seems to be a different bug than the one Neal sees after long
compiles.
Marcus
|