gcl-devel
[Top][All Lists]
Advanced

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

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


From: Gunther Schadow
Subject: Re: [Gcl-devel] Frame stack overflow - limit parameter to increase somewhere?
Date: Sat, 06 Dec 2003 01:23:55 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2

Hi Camm, thanks for your kind help. Well, I have compiled
in a 64k frssize and ihssize and 1M vssize and bdsize and
still no go. Then I set *multiply-stacks* to 1024 and
still. BTW, now it is the bind stack that overflows.
I set the *multiply-stacks* factor to 2048 and still.

What is suspicious to me is that the error always happens
at the same time after 26 minutes and the memory footprint
as reported by the OS doesn't go beyond a modest maximum
of 127M. Another DL classifier that is very similar but
closed source and of which I only have a binary based on
some Lucid or Allegro Lisp or whatever grows to over 400M
memory size (and still fails.) So, I know my data is stressing
it and that's why I need to get it working with the open
source program on GCL.

How can I test what the stack sizes actually are? Is there
some hard limit? I am just now testing it without the
multiply stacks factor because I suppose that it has no
effect on the time and memory size when the error occurs.

Is there some variables I can inquire at the time of the
error to see how big the stacks actually have grown? Or
do some other debugging?

thanks,
-Gunther

Camm Maguire wrote:

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











reply via email to

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