bugThe GNU Hurd - Bugs: bug #15299, ranlib causes kernel panics

 
 

bug #15299: ranlib causes kernel panics

Submitted by:  Samuel Thibault <sthibaul>
Submitted on:  Mon 26 Dec 2005 10:44:53 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: ConfirmedPrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: OpenReproducibility: None
Size (loc): NonePlanned Release: None
Effort: 0.00
Wiki-like text discussion box: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 30 Dec 2005 06:14:30 PM UTC, comment #1:

A wonderful way to reproduce this is to compile libjava, which is a 100MiB large static library, I haven't been able to compile libjava.a yet, and can reproduce this everytime.

Alfred M. Szmidt <ams>
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

Samuel Thibault <sthibaul>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follows 1 latest change.

Date Changed By Updated Field Previous Value => Replaced By
Fri 30 Dec 2005 06:14:30 PM UTCamsStatusNone=>Confirmed

Back to the top


Powered by Savane 3.1-cleanup