Re: infinite recursion?

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

[Gerhard:]
> > Message-Id: <199910162016.QAA31844@grail.cba.csuohio.edu>
> > Date: Sat, 16 Oct 1999 16:16:47 -0400 (EDT)
> > From: Michael Somos <somos@grail.cba.csuohio.edu>
> 
> > gp> f(n)=f(n-1)
> > gp> f(0)
> > 
> > I am sorry if this is a FAQ, but in the case of an obvious infinite
> > loop if I "control C" it, I get silently dumped back to the shell.
> > I guess this is better than a core dump, but is there any way to get
> > control again and not lose the sessions?
> 
> Something is strange here.  Yes, you are supposed to get back at
> the gp prompt... *if* you hit control-C fast enough.  Note that this
> is indeed an infinite recursion, not an infinite loop, and gp is
> consuming parts of its memory at a furious rate here.
> 
> Just tried this on sparc/Solaris where the process got a segmentation
> fault after a few seconds.  Then tried it on my old Linux (1.2.8) box
> where I had some difficulty killing the runaway process -- it seemed
> to be allocating extra memory.  Both gp's had been built from the same
> sources  (just pre-2.0.17), and both were running with default 4E6
> stack size.  Neither behaviour is entirely convincing to me.  I'd
> prefer the parser to stop with an error message when it runs out of
> space, and not (as it appeared to be doing) scribble over other parts
> of gp's memory...

This question arose some time ago already. It has nothing to do with the
parser: if you try it with a simple C program (e.g main(){ main();} ),
it'll do the same. It's the _process_ stack space which overflows. C frames
nest deeper and deeper in a fixed-size memory segment. An address outside
the physical size of the segment is touched and a SEGV is raised.

GP signal handler gets called at this point, but it also needs a stack
frame and there's no room for that. Hence a SEGV is .... Boom.

I see no nice portable way out of this (there's sigaltstack on Solaris as
Igor pointed), except by having a new default "recurdepth" that would
specify a maximal recursion depth for GP functions (as in Maple, except its
value seems to be hardcoded and not user-modifiable).

Problems:
1) it wouldn't protect you if you set it to too big a value. And what "too
big" means would depend on the physical RAM, compiler, OS, etc.

2) it would slow down a bit all user functions. [ Right now, nesting depth is
not tracked. It used to be when GP included a (very buggy) goto. ]

I may change it in the future (it's quite trivial to implement), but I'm
not sure it's that good an idea.

  Karim.
__
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://hasse.mathematik.tu-muenchen.de/ntsw/pari/