[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] cvs build on linux aborts
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] cvs build on linux aborts |
Date: |
04 Jan 2002 16:34:07 -0500 |
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