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

[Camm Maguire]

Greetings!

My apologies -- I assumed your first message was posted to the list --
now I can't find the original with the tarball.  I'd be happy to
reproduce what you are seeing here if you wouldn't mind resending.

But two questions some to mind:

1) Can you break the 1Gb stack limit by creating more than one extra
   thread in the child?

2) Is there any reason to expect that a 2Gb stack passed to setrlimit
   should be an error whereas a 1Gb stack should not?

I'm just trying to distinguish in my mind between 1) resource
exhaustion and 2) failure in libc error handling.

If 2Gb stack is alowable in principle, people can definitely make use
of the extra 1Gb, especially on conventional x86 Linux with shared
libs as the heap is limited to 1Gb.

Take care,

Gene Cooperman <address@hidden> writes:

> If you're confident that the o/main.c call to setrlimit() doesn't affect
> other potential applications of GCL, then you can just leave it as is.
> In ParGCL, I check the rl.rlim_cur of RLIM_STACK, and if it's too high,
> I reduce it to _only_ 1 GB of stack.
> 
> ParGCL now works fine in the current CVS.
> 
> In any case, please unpack the tarball, and run `make' in it, if you
> haven't done so yet.  It demonstrates a very simple bug.  I'm worried
> about other GCL applications.  For example, suppose the GCL interface
> to TCL/TK or some graphics package should create a child process.  Suppose,
> also, that the child process creates a thread.  In that case, you will
> definitely see the bug.  
> 
> In o/main.c, you could set the GCL rl.rlim_cur for the stack to a
> maximum of 1 GB.  This fixes the problem, and should not interfere
> with other uses within GCL.
>                                                       - Gene
> 
> On Sun, Dec 18, 2005 at 01:49:08PM -0500, Camm Maguire wrote:
> > 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
> 
> 
> 

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