Karim BELABAS on Sat, 7 Sep 2002 22:56:32 +0200 (MEST)


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

Re: gp: series bug


On Tue, 20 Aug 2002, Michael Somos wrote:
> In the current CVS version is a severe bug in power series. Example :
>
> parisize = 4000000, primelimit = 500000
> ? polcoeff(%1,-3)
>   ***   forbidden  ***   unknown type 32.
> ? polcoeff(%1,-4)
> %4 = 0
> ? polcoeff(%1,-5)
>   ***   the PARI stack overflows !
>   current stack size: 4000000 (3.815 Mbytes)
>   [hint] you can increase GP stack with allocatemem()
>
> ? \v
>           GP/PARI CALCULATOR Version 2.2.4 (development CHANGES-1.488)
>                  UltraSparc (MicroSparc kernel) 32-bit version
>               (readline v2.2 enabled, extended help not available)
>
> I can even get a seg fault :
>
> ...
> parisize = 4000000, primelimit = 500000
> ? polcoeff(1/(1-x),-2)
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x29625c in gcopy (x=0x719df8) at ../src/language/init.c:1305
> 1305        for (i=0; i<lontyp[tx];  i++) y[i]=x[i];
> (gdb) bt
> #0  0x29625c in gcopy (x=0x719df8) at ../src/language/init.c:1305
> #1  0x169814 in gtoser (x=0x719e10, v=0) at ../src/basemath/gen3.c:2260
> ...
>
> It seems to me that memory is being clobbered again. Probably in 'gdiv()'.

Simpler than that in fact.

1) There's a global variable named 'precdl' representing the current value of
the seriesprecision default, used by a number of routines ( this is quite bad
in itself, but can't be changed without wrecking compatibility ).

2) The polcoeff(P,n) code changed precdl, to a high enough value so
that Ser(P) would be computed with remainder O(x^(n+1))

3) Straightforward (erroneous) algebraic manipulation with degree(P) and n
led to a negative value of precdl.

4) Nobody boths to check that precdl had a legitimate value.

5) Boom.

6) as a funny side effect, the value of precdl = seriesprecision is not
restored by the error recovery code (polcoeff would have restored it,
but now the old value is lost for good). Hence

(21:48) gp > \ps
   seriesprecision = -98 significant terms

I've removed these hacks: now polcoeff can't be applied to a rational
function unless the denominator is a monomial. Hence the implicit conversion
to a series becomes useless.  The documentation was very sketchy here, so I
can claim that I'm not breaking compatibility by forbidding
polcoeff( 1/(1+x),1 )   [ requiring an explicit conversion Ser(1/(1+x)) ]

Cheers,

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas/
--
PARI/GP Home Page: http://www.parigp-home.de/