[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fork: mach_port_mod_refs: EKERN_UREFS_OWERFLOW

From: Thomas Schwinge
Subject: Re: fork: mach_port_mod_refs: EKERN_UREFS_OWERFLOW
Date: Mon, 6 Dec 2010 09:16:20 +0100
User-agent: Mutt/1.5.20 (2009-06-14)


On Tue, Nov 30, 2010 at 12:07:05PM +0100, I wrote:
> On Fri, Nov 26, 2010 at 01:22:05AM +0100, I wrote:
> > Should refs have simply been initialized to zero (as the zero value is
> > noneffective, and we'll set the ss->thread, etc. values later on)?
> At the moment, I don't have the time to analyze this further, but I'll
> simply give this glibc code change a try, and re-run the GCC testsuite
> afterwards.

Hung again; at another position (understandably), but with the same
symptoms as before.  (I'm assuming that `fork' isn't linked into some
relevant binary statically, but as GDB shows the shared library's
version, I think I'm fine.)

Here is a program to make this same thing happen in 30 minutes instead of
the testsuite's one or two days.

    $ ./fork_forever
    1817: 33
    1818: 37
    1819: 34
    1820: 35
    1821: 36
    1822: 38
    1823: 35
    1824: 36
    1825: 34
    1826: 37

The GDB backtrace looks very much like the one on

Oh, and interesting piece of maths: 1826 * 35.5 (roughly) = 65536.  So I
guess that we're ``simply'' leaking something with every fork call...
I'll try to find some time to go hunting.


Attachment: fork_forever.c
Description: Text Data

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]