Re: [Gcl-devel] cvs build on linux aborts

[Camm Maguire]

Great news!!  Now if I understand where we are, you will still run
into my sigsetjmp issue when running maxima make test.  If you can
confirm this, then we know we are on the same page.  (i.e. all the
other differences in our systems are likely irrelevant).

My bash puts an 8M limit on the stack.  Are you running bash?  What
does ulimt -a say?  In all truth, I am a bit unclear on exactly where
these limits get set.  But a 2Gig stack sounds a bit unreasonable.
Now this is just a dim recollection, but I thought Linux could address
4G with patches, so having both data and stack unlimited would divide
the mem in half between the two.  Hmmm.  Can you verify somehow that
the limits on your system are consistent with your addressing scheme,
and make sense?  If so, I don't know why gcl would complain with that
enormous stack, unless there is an integer overflow going on
somewhere.  If we can rely on getrlimit returning the truth, then the
*right* way to do this would be to keep the stack size setting as is,
and make sure that gcl can handle its maximum logical value.  This
sounds like work :-).  Otherwise, we could just introduce some
heuristic and set some artificial limit on the stack size.  Can you
try to find out where it breaks?  Just overwrite the rlim_cur value
with various test cases after the getrlimit call, but before it is
used in calculating cssize.

Thanks for the breakthrough!





robert read <address@hidden> writes:

> Oops, my bad, no SEGFAULT is occuring.  I set a break on error, and
> found the problem:
> 
> (gdb) run
> Starting program: /data1/rread/build/gcl/gcl/unixport/raw_gcl
> GCL (GNU Common Lisp)  April 1994  32768 pages
> loading ../lsp/export.lsp
> Initializing ../lsp/defmacro.o
> Initializing ../lsp/evalmacros.o
> Initializing ../lsp/top.o
> Initializing ../lsp/module.o
> loading ../lsp/autoload.lsp
> 
> >
> Breakpoint 2, error (s=0x8144433 "can't reset cs_limit") at main.c:334
> 334             if (catch_fatal>0 && interrupt_enable )
> (gdb) bt
> #0  error (s=0x8144433 "can't reset cs_limit") at main.c:334
> #1  0x0804ad9f in siLreset_stack_limits (arg=0) at main.c:677
> #2  0x080ac344 in LI1 ()
> #3  0x0805029a in quick_call_sfun (fun=0x81ae050) at eval.c:101
> #4  0x08050842 in funcall (fun=0x81ae050) at eval.c:164
> #5  0x08051959 in super_funcall (fun=0x81addec) at eval.c:748
> #6  0x0804a42e in main (argc=1, argv=0xbffff2a4, envp=0xbffff2ac) at
> main.c:313
> #7  0x400447ee in __libc_start_main () from /lib/libc.so.6
> 
> 
> After further digging, I noticed that getrlimit(RLIMIT_STACK) was
> returning MAX_INT, so the stack size appears to be unlimited.  Perhaps
> this is why this bug appears to be environment sensitive. For
> testing purposes, I commented out this line in main
> 
> #ifdef RLIMIT_STACK
>        getrlimit(RLIMIT_STACK, &rl);
>        /* cssize = rl.rlim_cur/4 - 4*CSGETA; */
> #endif 
> 
> and gcl works!  Now,  how to fix this properly?
> 
> robert
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

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