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

[robert read]

* Camm Maguire (address@hidden) [011231 14:43]:
> 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).

I'm not familiar with maxima.  Should I be using the version from
here, or is there a more current version? 
http://www.ma.utexas.edu/users/wfs/maxima.html

> 
> My bash puts an 8M limit on the stack.  Are you running bash?  What
> does ulimt -a say?  

$ ulimit -a
core file size (blocks)     0
data seg size (kbytes)      unlimited
file size (blocks)          unlimited
max locked memory (kbytes)  unlimited
max memory size (kbytes)    unlimited
open files                  1024
pipe size (512 bytes)       8
stack size (kbytes)         unlimited
cpu time (seconds)          unlimited
max user processes          10239
virtual memory (kbytes)     unlimited

> In all truth, I am a bit unclear on exactly where
> these limits get set.  

Well, on these systems (SuSE), this is set in /etc/profile.  It is
hardcoded to unlimited, which does seem a bit strange for a stack size.

> 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?  

Actually, I stack limit returned by getrlimit is RLIM_INFINITY, so I
changed this part of main() to this, which is perhaps closer to the
right thing:

#ifdef RLIMIT_STACK
       getrlimit(RLIMIT_STACK, &rl);
       if (rl.rlim_cur != RLIM_INFINITY)
         cssize = rl.rlim_cur/4 - 4*CSGETA;
       else
           ;
#endif     


> If so, I don't know why gcl would complain with that
> enormous stack, unless there is an integer overflow going on
> somewhere.  

Yep, the overflow happens in siLreset_stack_limits() in main.c, which
fails at this point:

#ifdef AV
       if (&arg > cs_org - cssize + 16)
          cs_limit = cs_org - cssize;
       else
          error("can't reset cs_limit");
#endif



> 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.

Isn't the stack size limit going to be more of factor of available
memory?   Perhaps we could create a new #define in bsd.h for
MAX_STACK_SIZE, and just set to a few megabytes or something.

> 
> Thanks for the breakthrough!
> 
> 

robert