PARI/GP Bug report logs - #329
gequal can return false if ^C is pressed at the wrong time

Package: pari; Maintainer for pari is Aurel Page <aurel.page@normalesup.org>; Source for pari is src:pari.

Reported by: Bill Allombert <allomber@math.u-bordeaux.fr>

Date: Mon, 26 Sep 2005 10:03:04 UTC

Severity: wishlist

Done: Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-submit-list@pari.math.u-bordeaux.fr, Karim.Belabas@math.u-psud.fr:
Bug#329; Package pari. (full text, mbox, link).


Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
New Bug report received and forwarded. Copy sent to Karim.Belabas@math.u-psud.fr.

Your message specified a Severity: in the pseudo-header, but the severity value important was not recognised. The default severity normal is being used instead. The recognised values are: critical, grave, normal, minor, wishlist.

(full text, mbox, link).


Message #5 received at submit@pari.math.u-bordeaux.fr (full text, mbox, reply):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: submit@pari.math.u-bordeaux1.fr
Subject: gequal can return false if ^C is pressed at the wrong time
Date: Mon, 26 Sep 2005 11:45:28 +0200
Package: pari
Severity: important
Version: 2.2.11/CVS

Hello Karim,
This is a known bug but I register it.

On my very slow laptop:
? allocatemem()
? A=mathilbert(200);
? B=A*Mod(1,2^607-1);
? A==B
---> Hit ^C <------
%4 = 0
? A==B
%5 = 1
? ##
  ***   last result computed in 470 ms.
(so you have 470ms to hit ^C).

Not only the ^C is not acknowledged, but the result is changed!

This is due to gequal using the CATCH library interface. It should
not trap siginter. This is a general problem with trap().

In my opinion, we should:
1) SIGINT should not be handled through err(). ^C is not an error.
2) Change the CATCH interface to never catch siginter.
3) Add a default(breakloop,1) equivalent to trap().
4) Add a function iferr(<code>,<iferrcmd>{,<ifnoterrcmd>}).
(Run code, if an error occur, run iferrcmd, else ifnoterrcmd).
5) Add a function errname() that return the name of the last error.
   (and optionally other data about the error).
6) Enhance error() so that it can take a errname() as input (so a user
can forward error).
7) Have a list of public error name and match PARI internal error
name to them. (so we may lose granularity but we can still catch all
errors.
8) remove trap(,,). The interface is too strange and ugly to be preserved.

This is quite a program, but it seems the only course of action to have
a useful exception handling facility.

Cheers,
Bill.



Severity set to `grave'. Request was from Bill Allombert <allomber@math.u-bordeaux.fr> to control@pari.math.u-bordeaux.fr. (full text, mbox, link).


Information forwarded to bug-submit-list@pari.math.u-bordeaux.fr, Karim.Belabas@math.u-bordeaux.fr:
Bug#329; Package pari. (full text, mbox, link).


Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Karim.Belabas@math.u-bordeaux.fr. (full text, mbox, link).


Message #12 received at 329@pari.math.u-bordeaux.fr (full text, mbox, reply):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr>
Cc: 329@pari.math.u-bordeaux1.fr, 1064-done@pari.math.u-bordeaux.fr, Igor Schein <igorschein@gmail.com>
Subject: Re: Bug#1064: variation of bug 337
Date: Fri, 11 Jun 2010 22:29:02 +0200
On Fri, Jun 11, 2010 at 07:34:53AM +0200, Karim Belabas wrote:
> * Bill Allombert [2010-06-11 01:05]:
> > On Thu, Jun 10, 2010 at 12:07:50PM -0400, Igor Schein wrote:
> > > Package: pari
> > > Version: svn-12423
> > > 
> > > ? factorpadic(quadhilbert(401),4,precision(.),1)
> > > Segmentation fault
> > > 
> > > \\ and the session dies
> > 
> > This also happen with
> >  factorpadic(x^16+16,4,3,1)
> > 
> > As usual there are several issues:
> > 
> > 1) 4 is not a prime number so it is a BIB.
> 
> Agreed.
> 
> > 2) factorpadic2() actually use ROUND4, because padicff call nfmaxord(,,0)...
> 
> Agreed. Actually a slighly inefficient version of ROUND4 (which is
> originally a p-adic factorization algorithm, we do some extra work to
> get a p-maximal order...)
> 
> It should use flag = nf_ROUND2, instead of 0. 
> 
> > 3) nfmaxord use CATCH/RETRY/ENDCATCH, which is not correct: when an error
> > occurs, a new error handler is added. Later, ENDCATCH only remove the last
> > handler, so the first one is still active but out of scope. This cause a crach
> > when a later error cause a longjmp to it.
> > A correct definition would be:
> > #define RETRY else __catcherr = err_catch(__err, &__env); {
> > #define TRY else { __catcherr = err_catch(__err, &__env);
> 
> Good catch !
> 
> > 4) Another unrelated problem with the CATCH/TRY/ENDCATCH interface is that the
> > error handler is active inside the CATCH part which is likely to cause an
> > oo-loop in case of errors inside the CATCH part.
> 
> I think this can be solved by adding a true/false 'inhibit' flag to the 
> 'cell' handler struct, effectively disably the handler if set to true.
> The CATCH part would set it, the RETRY, would unset it, and TRY would
> ignore it.
> 
> This more or less forces us to have err_catch return the cell* handler
> itself (so that it can be manipulated as above) instead of its index in the
> handler stack. The 'cell' struct might as well contain the index 'n'
> then...
> 
> (And err_leave() woudl take a cell* as argument.)
> 
> Since this also forces us to expose the private cell struct, its name
> should be changed. pari_err_handler ?
> 
> Then the whole thing could be documented :-)

I would rather replace the whole thing by iferr and get rid of the ERRCATCH
stack completly. That would be something like:

#define CATCH(varname) {         \
  jmp_buf __env, *__iferr_old=iferr_env; \
  iferr_env = &__env; \
  if (setjmp(*iferr_env)) \
  { \
    GEN varname = global_err_data; \
    iferr_env = iferr_old; \
    {

#define RETRY } {
#define TRY } else {
#define ENDCATCH } iferr_env = iferr_old; } 

and then you would write

CATCH(er)
{
  GEN x;
  if (gel(er,1)!=invmoder) pari_error(er);
  x = gel(er,3);
  ...
} RETRY {
...
} ENDCATCH

> > With this change, we get:
> > ? factorpadic(x^16+16,4,3,1)
> >   ***   at top-level: factorpadic(x^16+16,
> >   ***                 ^--------------------
> >   *** factorpadic: impossible inverse modulo: Mod(2, 4).
> 
> Can you commit the part corresponding to 1), 2), 3) ?

Well I have commited a fix for 2) and 3). 

I close this report because the remaining issue are far outside its scope.

I copy bug #329

Cheers,
Bill.



Information forwarded to bug-submit-list@pari.math.u-bordeaux.fr, Karim.Belabas@math.u-bordeaux.fr:
Bug#329; Package pari. (full text, mbox, link).


Acknowledgement sent to Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Karim.Belabas@math.u-bordeaux.fr. (full text, mbox, link).


Message #17 received at 329@pari.math.u-bordeaux.fr (full text, mbox, reply):

From: Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr>
To: 329@pari.math.u-bordeaux.fr
Subject: Re: gequal can return false if ^C is pressed at the wrong time
Date: Fri, 18 Feb 2011 22:47:24 +0100
* Bill Allombert [2005-09-26 12:48]:
> This is a known bug but I register it.
> 
> On my very slow laptop:
> ? allocatemem()
> ? A=mathilbert(200);
> ? B=A*Mod(1,2^607-1);
> ? A==B
> ---> Hit ^C <------
> %4 = 0
> ? A==B
> %5 = 1
> ? ##
>   ***   last result computed in 470 ms.
> (so you have 470ms to hit ^C).

Most of the underlying issues (described hereafter) have been adressed.
Changing the severity to wishlist.

> Not only the ^C is not acknowledged, but the result is changed!

No longer occurs in svn.

> This is due to gequal using the CATCH library interface. It should
> not trap siginter. This is a general problem with trap().

No longer true in svn.

> In my opinion, we should:
> 1) SIGINT should not be handled through err(). ^C is not an error.

Done.

> 2) Change the CATCH interface to never catch siginter.

Done.

> 3) Add a default(breakloop,1) equivalent to trap().

Done.

> 4) Add a function iferr(<code>,<iferrcmd>{,<ifnoterrcmd>}).
> (Run code, if an error occur, run iferrcmd, else ifnoterrcmd).

The git branch bill-iferr contains a patch. NOT merged yet.

> 5) Add a function errname() that return the name of the last error.
>    (and optionally other data about the error).
> 6) Enhance error() so that it can take a errname() as input (so a user
> can forward error).
> 7) Have a list of public error name and match PARI internal error
> name to them. (so we may lose granularity but we can still catch all
> errors.
> 8) remove trap(,,). The interface is too strange and ugly to be preserved.

To be done someday. => Wishlist.

Cheers,

    K.B.
--
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux1.fr/~belabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
`



Severity set to `wishlist'. Request was from Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr> to control@pari.math.u-bordeaux.fr. (full text, mbox, link).


Reply sent to Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr>:
You have taken responsibility. (full text, mbox, link).


Notification sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Bug acknowledged by developer. (full text, mbox, link).


Message #24 received at 329-close@pari.math.u-bordeaux.fr (full text, mbox, reply):

From: Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr>
To: 329-close@pari.math.u-bordeaux.fr
Subject: Re: gequal can return false if ^C is pressed at the wrong time
Date: Tue, 17 Jan 2012 19:03:38 +0100
* Karim Belabas [2011-02-18 22:47]:
> * Bill Allombert [2005-09-26 12:48]:
[...]
> > 4) Add a function iferr(<code>,<iferrcmd>{,<ifnoterrcmd>}).
> > (Run code, if an error occur, run iferrcmd, else ifnoterrcmd).
> 
> The git branch bill-iferr contains a patch. NOT merged yet.

Now applied to 'master' branch.

> > 5) Add a function errname() that return the name of the last error.
> >    (and optionally other data about the error).

Done.

> > 6) Enhance error() so that it can take a errname() as input (so a user
> > can forward error).

Done.

> > 7) Have a list of public error name and match PARI internal error
> > name to them. (so we may lose granularity but we can still catch all
> > errors.

Done. 

> > 8) remove trap(,,). The interface is too strange and ugly to be preserved.

The function is now marked "obsolete".

Closing this long-standing report. Thanks !

    K.B.
-- 
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux1.fr/~belabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
`



Send a report that this bug log contains spam.


Bill Allombert <allomber@math.u-bordeaux.fr>. Last modified: Thu Mar 28 19:15:11 2024; Machine Name: pari

PARI/GP Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.