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

[Camm Maguire]

Greetings!  You should be able to do this interactively at runtime,
e.g. without recompiling, as follows:

 (SETQ SI::*MULTIPLY-STACKS* 4)

This increases all stack sizes by a factor of 4 using 'malloc'.  If
you can pin your failure down to a single command, run a command like
the above and repeat your failing command, then iterate until you
failure goes away.

I believe the multiply-stacks can only be set like this at toplevel,
so that attempting to have it run automatically on stack exhaustion in
the middle of running code is not an option, though I suppose we could
look into this to make sure.

Please keep us posted.

Take care,

Gunther Schadow <address@hidden> writes:

> Hi Camm and other GCL developers, thanks, I could now get to
> the GCL 2.6.1 version. And I can configure larger stack limits.
> However, it turns out that I am not good at guessing how much
> I need. I increased everything by a factor of 8 and still
> ran into trouble. Problem is it takes 20 minutes or more for it to
> exhaust its limits, so testing is slow.
> 
> I am wondering: would it not be possible to do memory allocation
> completely dynamically? I see that you use those FRSSIZE and other
> *SSIZE constants to dimension actual arrays that are
> used for those stacks. Now either I should just max those out
> completely or a more graceful way would be to use malloc and
> realloc to add pages to those stacks. Hmm, I guess realloc would
> over time waste address space in holes. I guess I should just
> max those out entirely and let the virtual memory subsystem
> take care of the paging.
> 
> I wonder how other LISP systems are dealing with this?
> 
> regards
> -Gunther
> 
> 
> 
> Camm Maguire wrote:
> 
> > Greetings!  Yes, savannah/subversions is apparently down until
> > tomorrow.  Did you try the utexas url?  This should work.
> > Take care,
> > Gunther Schadow <address@hidden> writes:
> >
> >>Camm, this is still a no go:
> >>
> >>cvs [login aborted]: connect to subversions.gnu.org(199.232.41.2):2401 
> >>failed: Connection timed out
> >>
> >>traceroute:
> >>  7   121 ms   420 ms   341 ms  206.108.108.213
> >>  8   160 ms   411 ms   310 ms  64.230.223.41
> >>  9   130 ms   200 ms   311 ms  206.108.103.129
> >> 10   230 ms   401 ms   310 ms  64.230.242.98
> >> 11   331 ms   410 ms   401 ms  206.108.104.170
> >> 12   220 ms   411 ms   410 ms  199.235.123.253
> >> 13     *        *        *     Request timed out.
> >>
> >>seems like the last hop is offline or firewalled?
> >>
> >>-Gunther
> >>
> >>Camm Maguire wrote:
> >>
> >>>Greetings!  Unfortunately, ftp.gnu.org is still locked due to the
> >>>recent compromise, and to make matters worse, so are the Debian sites.
> >>
> >>sounds to me as if there is one of two problems (1) the OS
> >>that both gnu.org and debian is relying on is insecure or (2) there is
> >>just starting to be too much of a monoculture of this OS around so
> >>it's little better that M$ Doors.
> >>
> >>
> >> -- 
> >>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
> >>
> >>
> >>
> >>
> >>
> >>
> >
> 
> -- 
> 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
> 
> 
> 
> 
> _______________________________________________
> 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