Fix PARI error handling

[vbraun]

Instead of catching whatever PARI writes to pariErr, we should use a callback function cb_pari_err_handle. That way, we don't need special tricks for warnings anymore.

Moreover, we also get access to the "error data" (a t_ERROR object) which we store in the exception.

Depends on #12142 Depends on #14873

CC: @jdemeyer

Component: packages: standard

Keywords: pari error signal

Author: Jeroen Demeyer

Branch/Commit: 2d532fc

Reviewer: Peter Bruin

Issue created by migration from https://trac.sagemath.org/ticket/14894

[jdemeyer]

comment:40

I asked pari-dev about a callback function instead of longjmp() for PARI error handling (i.e. option 3 above).

[pjbruin]

comment:41

Replying to @jdemeyer:

I asked pari-dev about a callback function instead of longjmp() for PARI error handling (i.e. option 3 above).

There is the callback function cb_pari_handle_exception, but I don't quite see how to use this without any longjmp(); see comment:34. Hence two questions:

• Would a new callback function really be needed (e.g. because it has to be called at a different moment than cb_pari_handle_exception)?
• Does the option 3 that you have in mind somehow avoid longjmp(), or do you propose to do the longjmp() inside a common error-handling function for signals and PARI errors?

[jdemeyer]

comment:42

Replying to @pjbruin:

There is the callback function cb_pari_handle_exception

The problem with that callback is that it is called after printing the error message. For Sage, we don't want the error to be printed.

My approach would still use a longjmp() to jump to the setjmp() inside sig_on(). It would avoid an additional setjmp() call for PARI.

[pjbruin]

comment:43

Replying to @jdemeyer:

Replying to @pjbruin:

There is the callback function cb_pari_handle_exception

The problem with that callback is that it is called after printing the error message. For Sage, we don't want the error to be printed.

Couldn't we prevent printing the error message by using a custom pariErr like we already do for pariOut? Besides not having to patch PARI to add another callback, this has the additional advantage that the error text can be stored for possible inspection.

My approach would still use a longjmp() to jump to the setjmp() inside sig_on(). It would avoid an additional setjmp() call for PARI.

Good, that is what I suspected.

[jdemeyer]

comment:44

Replying to @pjbruin:

Couldn't we prevent printing the error message by using a custom pariErr like we already do for pariOut? Besides not having to patch PARI to add another callback, this has the additional advantage that the error text can be stored for possible inspection.

That was my original idea but there are some complications, for example the printing of an extra newline in err_init() and the use of ANSI escape sequences for colours.

[pjbruin]

comment:45

Replying to @jdemeyer:

Replying to @pjbruin:

Couldn't we prevent printing the error message by using a custom pariErr like we already do for pariOut? Besides not having to patch PARI to add another callback, this has the additional advantage that the error text can be stored for possible inspection.

That was my original idea but there are some complications, for example the printing of an extra newline in err_init() and the use of ANSI escape sequences for colours.

I see. But wouldn't it be a more satisfactory solution to have PARI do those things only if the output is connected to a terminal (using isatty)? This would still require a patch, of course.

[pjbruin]

comment:47

Now that we have a better error-handling mechanism (#9640), is there anything specific that needs to be done in this area when upgrading PARI? Should this rather become a general PARI upgrade ticket, or be closed as a duplicate of #9640?

Also, do we want to upgrade to PARI 2.6.x or wait for 2.7.x (even minor version = development, odd = stable)? In January there will be an "Atelier PARI/GP" where planning for PARI 2.9 is on the agenda (http://pari.math.u-bordeaux.fr/Events/PARI2014/), which suggests that a 2.7 release is in the pipeline.

[jdemeyer]

comment:48

I would say: let this ticket quietly sit here and let's look at it again when PARI-2.7 is released.

[pjbruin]

Changed author from Peter Bruin to none

[pjbruin]

comment:49

In the light of #9640 and #15767, I think this ticket is no longer relevant and suggest to close it.

[jdemeyer]

comment:50

I think that this ticket is still relevant, since PARI-2.7.x has improved error handling mechanisms which we don't use.

[jdemeyer]

comment:51

I think we do need to reconsider the approach though. Personally I like to use Karim's proposal from http://pari.math.u-bordeaux.fr/archives/pari-dev-1309/msg00002.html, but that hasn't been implemented upstream yet.

[jdemeyer]

Author: Peter Bruin

[jdemeyer]

comment:53

I'm willing to look into this ticket, but not right now.

[jdemeyer]

Description changed:

--- 
+++ 
@@ -1,40 +1 @@
-Pari GIT has made significant changes to the error handling code, which will require us to make some changes to Sage.
-
-This ticket reimplements PARI error handling inside Cython code using macros provided by `pari/paricom.h` instead of undocumented functions that no longer exist in PARI 2.6.  The new syntax is
-
-```
-sage_pari_catch()
-... code ...
-sage_pari_catch_end()
-```
-Inside such a block one can put conditions like
-
-```
-if [some condition]:
-    sage_pari_catch_reset()
-    [return or raise exception]
-```
-
-The new functions catch PARI errors and also call `sig_on()` and `sig_off()` to enable interrupt handling.  This replaces the current hack of overriding `sig_on()` and `sig_off()`.
-
-Since `sage_pari_catch()` and `sage_pari_catch_end()` are C macros containing complementary braces, they *must* be on the same level in Cython code.  This means that several functions in `sage/libs/pari/gen.pyx`, most importantly `new_gen()`, no longer call `sig_off()` or its replacement `sage_pari_catch_end()`.  Instead of
-
-```
-sig_on()
-return new_gen(something returning GEN)
-```
-one therefore has to write
-
-```
-cdef gen result
-sage_pari_catch()
-result = new_gen(something returning GEN)
-sage_pari_catch_end()
-return result
-```
-
-This new approach fixes several (potential) problems with the existing one; see [#14873 comment:9](https://github.com/sagemath/sage/issues/14873#comment:9).
-
-When upgrading to PARI 2.6, the only remaining change to be made (hopefully) is to replace the macros `CATCH`, `ENDCATCH`, `RETRY` and `CATCH_RELEASE` by `pari_CATCH`, `pari_ENDCATCH`, `pari_RETRY` and `pari_CATCH_reset`.
-
-Apply: [attachment: trac_14894-pari_catch-folded.patch](https://github.com/sagemath/sage-prod/files/10658143/trac_14894-pari_catch-folded.patch.gz)
+Instead of catching whatever PARI writes to `pariErr`, we should use a callback function `cb_pari_prehandle_exception`. That way, we don't need special tricks for warnings anymore.

[jdemeyer]

Branch: u/jdemeyer/ticket/14894

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Commit: 0602271

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

0602271

Use cb_pari_err_handle() to handle PARI errors

[jdemeyer]

Description changed:

--- 
+++ 
@@ -1 +1,3 @@
-Instead of catching whatever PARI writes to `pariErr`, we should use a callback function `cb_pari_prehandle_exception`. That way, we don't need special tricks for warnings anymore.
+Instead of catching whatever PARI writes to `pariErr`, we should use a callback function `cb_pari_err_handle`. That way, we don't need special tricks for warnings anymore.
+
+Moreover, we also get access to the "error data" (a `t_ERROR` object) which we store in the exception.

[jdemeyer]

Changed reviewer from Jeroen Demeyer to none

[jdemeyer]

Changed author from Peter Bruin to Peter Bruin, Jeroen Demeyer

[pjbruin]

Reviewer: Peter Bruin

[pjbruin]

Changed author from Peter Bruin, Jeroen Demeyer to Jeroen Demeyer

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 0602271 to 2d532fc

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

2d532fc

Move PariError to handle_error.pyx; add sig_block() where needed

[vbraun]

Changed branch from u/jdemeyer/ticket/14894 to 2d532fc