[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somew

From: Camm Maguire
Subject: Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?
Date: 04 Dec 2003 17:23:10 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  Unfortunately, ftp.gnu.org is still locked due to the
recent compromise, and to make matters worse, so are the Debian sites.
Right now we're flying on one mirror wing, and that is


CVS access can be had at

cvs -d:pserver:address@hidden:/cvsroot/gcl 

Use -r Version_2_6_1 when checking out the stable branch, and omit
this flag when checking out the development branch.

Soon, this should work too:


and then ftp.gnu.org, when access is re-enabled.  As soon as this
latter event comes about, I'll put the latest CVS 2.6.1 out as a 2.6.2
tarball and retag the CVS branch.

Take care,

Gunther Schadow <address@hidden> writes:

> O.K. that's wonderful. Now where is the up to date release of GCL?
> When I go to what seems like the official GCL site
> http://www.gnu.org/software/gcl/
> the latest release I get is 2.5.3. Same from ftp.gnu.org and
> prep.ai.mit.edu won't work any more. From the utexas cvs server
> (anonymous pserver) I get 2.5.0 as the latest and subversions.gnu.org
> doesn't seem to allow me in neither using
> RSH nor SSH. So I am at a loss. Is there anonymous CVS, where, how?
> Is there an up to date release tarball FTP site, where? Thank you,
> -Gunther
> Camm Maguire wrote:
> > Greetings!
> > 1) What GCL version?  Recent stable versions (2.6.1) have increased
> >    the default stack size.
> > 2) You can increase it further at compile time with
> >    --enable-frssize=... 3) You can set the variable
> > si::*multiply-stacks* to a multiplicative
> >    factor, e.g. 2,4,etc. by which to increase the stack sizes at
> >    runtime. Please let us know if you still have problems.
> > Take care,
> > Gunther Schadow <address@hidden> writes:
> >
> >>Hi, sorry, I don't find any better place to post this question than
> >>the devel list (well, once in 1993 I was hacking the KCL and AKCL code
> >>myself trying to port it to 386BSD, so I might be excused.)
> >>
> >>I am working here with a description logic classifier in GCL and it's
> >>bailing out with a "Frame stack overflow" error with a frame
> >>stack of height 653. Normally I would think that this is a termination
> >>issue, but this algorithm is tested and believed to work, yet my
> >>data is pretty big, so I would expect it to run long and deep. But
> >>why should there even be a stack overflow on a machine with virtual
> >>memory? I have set ulimit -s unlimited but to no avail. Is there some
> >>maximum frame stack size parameter in GCL that could be increased?
> >>
> >>I fgrepped the source code and could find nothing.
> >>
> >>I appreciate any hint. I would really need a large memory model for my
> >>purpose.
> >>
> >>thanks,
> >>-Gunther
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Gcl-devel mailing list
> >>address@hidden
> >>http://mail.gnu.org/mailman/listinfo/gcl-devel
> >>
> >>
> >>
> >
> -- 
> Gunther Schadow, M.D., Ph.D.                    address@hidden
> Medical Information Scientist      Regenstrief Institute for Health Care
> Adjunct Assistant Professor        Indiana University School of Medicine
> tel:1(317)630-7960                         http://aurora.regenstrief.org

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]