[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) |
Hello!
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
[hangs]
The GDB backtrace looks very much like the one on
<http://www.bddebian.com/~hurd-web/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow/>.
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.
Regards,
Thomas
fork_forever.c
Description: Text Data
signature.asc
Description: Digital signature