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

 
 

bug #15299: ranlib causes kernel panics

Submitter:  Samuel Thibault <sthibaul>
Submitted:  Mon 26 Dec 2005 10:44:53 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Invalid Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Closed Reproducibility:  None
Size (loc):  None Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 11 Feb 2016 10:17:41 PM UTC, comment #2: 

This bug report is 15 years old, the allocator in question is gone, and we're in the middle of revamping the allocator once again.  The report is no longer relevant.  Feel free to reopen if you disagree.

Justus Winter <teythoon>
Group Member
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: -email is 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>, -email is 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: -email is 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>,
        -email is 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>,
        -email is 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: -email is 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>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by teythoon (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-02-11 teythoon StatusConfirmed Invalid
        Open/ClosedOpen Closed
    2005-12-30 ams StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code