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

[Camm Maguire]

Greetings!  OK, I've just commited changes which I believe make
libc2.2.4 on Linux 386 work.  Please check them out!  I took your
MAX_STACK_SIZE suggestion.

Other porting news:

Linux arm: Successful gcl build with the (as yet uncommited) bfd
           library patches.  Still errors in compiling maxima :-(
           "Dots appeared illegally", so it must be some memory or
           loading issue.

Linux sparc and Linux m68k:  Apparently can build but for one error,
           again with the bfd patches.  When initializing defstruct,
           which in turn calls fScopy_array_portion, some memory
           corruption appears to bring the build to a halt.
           Everything else loades and compiles fine apparently.  Have
           yet to chase this one down.  Identical tree (with bfd)
           compiles and runs maxima's make test without error on
           i386. 

Linux ppc:  Got the relocations working with bfd, but now the machine
            I was testing on has gone down, so more news later.

Take care,

robert read <address@hidden> writes:

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

yes, I would suggest testing with maxima 5.6 at this site, for now.


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