[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: |
05 Dec 2003 19:07:52 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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
- [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Gunther Schadow, 2003/12/04
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Camm Maguire, 2003/12/04
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Gunther Schadow, 2003/12/04
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Camm Maguire, 2003/12/04
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Gunther Schadow, 2003/12/04
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Camm Maguire, 2003/12/04
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Gunther Schadow, 2003/12/05
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?,
Camm Maguire <=
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Gunther Schadow, 2003/12/06
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Gunther Schadow, 2003/12/06
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Gunther Schadow, 2003/12/06
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Vadim V. Zhytnikov, 2003/12/06
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Camm Maguire, 2003/12/11
- Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?, Camm Maguire, 2003/12/11