gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: GCL bug: o/main.c


From: Camm Maguire
Subject: [Gcl-devel] Re: GCL bug: o/main.c
Date: 18 Dec 2005 13:49:08 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Gene Cooperman <address@hidden> writes:

> Camm,
> 
> In GLC's o/main.c, GCL seems to trigger an existing bug in glibc:setrlimit().
> I've filed a bug report on it through Debian, and I'm attaching my
> bug report.
> 
> In short, o/main.c attempts to use setrlimit() to set rlim_cur to something
> unnaturally high (on my machine, to 0x7fb8ffff, which is about 2 GB).
> setrlimit silently accepts this, and when a child process tries to
> call pthread_create(), the child process reports:
>  pthread: Cannot allocate memory
>  pthread: pthread.c:22: main: Assertion `0 == pthread_retval' failed.
> 
> This bug affects ParGCL (and I patched ParGCL in the CVS on Friday to
> work around this), but it would affect any foreign function that
> calls pthread_create() inside a child process.
> 

Actually, this allowance for maximal stack usage is intentional, and
people are using it.  The stack also comes particularly into play when
using 'si::fork in our current implementation, not to mention
governing the maximal depth of gc cons marking and other deeply
recursive functions as well.  So in general we want to give the user
as much stack space as possible.  On current x86 Linux, which the heap
is ususally limited to 1Gb by shared memory placement, one actually
has access to almost twice as much in stack space!

What is odd is that the pthread implementation appears to be actually
copying the stack for the thread, rather than using some sort of copy
on write mechanism like fork().  Hmm, probably a good reason for this
somewhere. 

In any cae, I think the solution for us is to limit cssize in
configure to something reasonable when pargcl is selected.  Any iea on
what this should be?  Looks like it might be the default value divided
by the expected number of threads.  Perhaps we should document this
behavior somewhere too.

Take care, and thanks for your outstanding work in this area!



> I'm attaching my Debian bug report, and also a tarball that will let
> you easily reproduce the bug.  Just do:
>   tar zxvf BUG-glibc.tar.gz
>   cd BUG-glibc
>   make
> 
> The fix for GCL is probably to adjust the configure file.  I'll leave
> you to do that, since it could affect other issues in GCL.
> [ Tell me, if you prefer that I find and apply a fix. ]
>                                                       Best wishes,
>                                                       - Gene
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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