Re: BUG: In the Windows build of Pari, ellinit dies if given slightly peculiar parameters

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

[Tom Womack:]
> E = ellinit([-760071579/16348,
> 4513128515902125/16703569, -12561985602810, -73002352832265150, -19724467285
> 718645401743750]);
> 
> causes Pari to give a 'the stack overflows' message after a few seconds,
> regardless of the stack size.
>
> I can't see anything useful in the debug output [I've set debug and
> debugmem]; I suspect someone who understands the internals of ellinit() will
> be able swiftly to find out why this is going wrong, but I'm not such a
> person.

This doesn't happen on my Ultra and there is no use of the random
numbers generator during the ellinit call. I suspect some object corruption
taking place, although I hardly see any Windows specific code in PARI that
could create such a problem (deals mostly with input/output). First, does the
problem occur during

  E = ellinit([-760071579/16348, 4513128515902125/16703569, -12561985602810, -73002352832265150, -19724467285718645401743750], 1)

If not, does polroots(4*x^3 + E.b2 * x^2 + 2*E.b4 * x + E.b6) succeed ?

Second, did you compile the GP binary yourself (if so how ?) or did you fetch
Bill Daly's binary on the megrez server ?  Can you possibly debug GP on your
system ? (if not, I'll have a try with cygwin + gdb + gcc next week).

> [a feature-request: would it be possible to have something like
> default(trace,1) to print the names and parameters of library calls as they
> occur (maybe even default(trace,elliptic,1) so you don't get informed of
> every addition in a program)? The ellinit went wrong in the middle of a
> rather fiddly nest of procedures, and I ended up having to insert print()
> commands every other line throughout the program to find where it was
> crashing]

It would be possible, and is (in an equivalent form) mostly there in the TODO
list. At the time being you can use 'trap': I have a file containing the line

    trap()

read from my gprc. This causes the script to stop after an error occurs, just
before the recovery code is exercised. GP indicates the place where the error
took place so you can see where the problem is and lets you type commands so
that you can inspect the variables before they are restored to their initial
values.

Cheers,

  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://www.parigp-home.de/