|Bill Allombert on Tue, 8 Apr 2003 11:21:45 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: GMP kernel and stack abuse|
On Mon, Apr 07, 2003 at 04:54:51PM -0700, Ilya Zakharevich wrote: > On Mon, Apr 07, 2003 at 11:50:51PM +0200, Bill Allombert wrote: > > > > Using the GMP kernel, my session dies on a huge division! > > > > > > > > This is a general problem in GMP, which may allocate a huge amount of > > > > memory in the process stack space (using alloca). The best solution so far > > > > is to increase the maximum size of the process stack segment before > > > > starting gp from the shell. Alternatively, you might wish to configure GMP > > > > with > > > > > > > > configure --enable-alloca=malloc-noreentrant > > > > > > > > but this will slow down GMP. > > > > > > We *know* the stack limit. Why not use this knowledge to substitute > > > our alloca()? > > > > Does not it require recompiling libgmp ? > > So do it. ;-) ... then I am afraid we cannot really avoid pointing at the FAQ. Most people just use whatever libgmp is provided by their software distribution/sysadmin and the default is to use the real alloca. The FAQ already suggest to recompile libgmp with configure --enable-alloca=malloc-noreentrant We could provide a way to recompile GMP with a TMP_ALLOC interface that use the PARI stack instead of the system stack, but it will be a burden for most people to have to recompile a modified GMP version. > > The stack overflow here is of the order of tens of megabytes. > > So it is not hard to detect. ;-) PARI is able to catch small stack overflow and output a deep recursion error. Is it really possible to catch large stack overflow? Cheers, Bill..