Inconsistent mpz_t state after interrupted sig_realloc()

[embray]

TODO

☐	Use sig_occurred() to check whether an exception from Cysignals is currently being handled while in Integer.tp_dealloc. If so, assume that the state of the object's mpz struct may not be consistent, so do not call mpz_clear on it and do not place it back in the free pool.
☐	Don't forget to re-enable the test that was disabled in #25137 in order to test that this is fixed.

---

As discussed on sage-devel, I'm fairly consistently (roughly 9 times out of 10) getting the following failure on Cygwin:

sage -t --warn-long 164.8 src/sage/structure/coerce_actions.pyx
**********************************************************************
File "src/sage/structure/coerce_actions.pyx", line 786, in
sage.structure.coerce_actions.IntegerMulAction._repr_name_
Failed example:
    IntegerMulAction(ZZ, GF5)
Expected:
    Left Integer Multiplication by Integer Ring on Finite Field of size 5
Got:
    Left Integer Multiplication by Integer Ring on Finite Field of size 1
**********************************************************************
1 item had failures:
   1 of   4 in sage.structure.coerce_actions.IntegerMulAction._repr_name_
    [143 tests, 1 failure, 3.30 s]
----------------------------------------------------------------------
sage -t --warn-long 164.8 src/sage/structure/coerce_actions.pyx  # 1
doctest failed

Obviously Sage doesn't even allow creation of an order 1 field. In fact, I traced the cause of this to a specific line in FiniteFieldFactory.create_key_and_extra_args where, by chance, an Integer with a value of 1 is constructed (using fast_tp_new) whose (mp_limb*)(Integer.value._mp_d) member is assigned the same address as the _mp_d of the Integer that happens to hold the field's order.

The result is that the order is then set to 1 as well. This happens after the check that order>1 so creation of the field still succeeds. Clearly there is a subtle bug either in fast_tp_new, or in the memory allocator itself.

Depends on #27073

CC: @jdemeyer @xcaruso

Component: cython

Author: Jeroen Demeyer

Branch/Commit: 521bac9

Reviewer: Erik Bray

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

[embray]

Description changed:

--- 
+++ 
@@ -20,6 +20,6 @@
 doctest failed
 ```
 
-Obviously Sage doesn't even allow creation of an order 1 field.  In fact, I traced the cause of this to an exact line, in `FiniteFieldFactory.create_key_and_extra_args` where, by chance, an `Integer` with a value of `1` is constructed (using `fast_tp_new`) whose `(mp_limb*)(Integer.value._mp_d)` member is assigned the same address as the `_mp_d` of the `Integer` that happens to hold the field's order.
+Obviously Sage doesn't even allow creation of an order 1 field.  In fact, I traced the cause of this to a *specific* line in `FiniteFieldFactory.create_key_and_extra_args` where, by chance, an `Integer` with a value of `1` is constructed (using `fast_tp_new`) whose `(mp_limb*)(Integer.value._mp_d)` member is assigned the same address as the `_mp_d` of the `Integer` that happens to hold the field's order.
 
 The result is that the `order` is then set to `1` as well.  This happens *after* the check that `order>1` so creation of the field still succeeds.  Clearly there is a subtle bug either in `fast_tp_new`, or in the memory allocator itself.

[jdemeyer]

comment:2

We should also consider the possibility of a bug in Cygwin, as this has not been observed on other platforms.

[embray]

comment:3

Replying to @jdemeyer:

We should also consider the possibility of a bug in Cygwin, as this has not been observed on other platforms.

Yep, I agree. Though I think there's also a possibility of a subtle bug. The code around which this is happening looks like this:

            order = Integer(order)
            if order <= 1:
                raise ValueError("the order of a finite field must be at least 2")

            if order.is_prime():
                p = order
                n = Integer(1)

It's the last line, n = Integer(1) where that Integer has the same _mp_d as order for some reason. Also in this case order is already passed in as an Integer, so I'm wondering if there's some subtle bug around order = Integer(order).

[embray]

comment:4

Maybe not--by the time I get to order = Integer(order) the next two Integers in the pool already shared the same _mp_d:

(gdb) p __pyx_v_4sage_5rings_7integer_integer_pool_count
$37 = 7
(gdb) p ((struct __pyx_obj_4sage_5rings_7integer_Integer *)__pyx_v_4sage_5rings_7integer_integer_pool[6]).value
$38 = {{_mp_alloc = 1, _mp_size = 0, _mp_d = 0x602b85c40}}
(gdb) p ((struct __pyx_obj_4sage_5rings_7integer_Integer *)__pyx_v_4sage_5rings_7integer_integer_pool[5]).value
$39 = {{_mp_alloc = 1, _mp_size = 0, _mp_d = 0x602b85c40}}

I'm going to add in some tracing and see if that reveals anything (or makes the problem go away entirely which would point more toward a Cygwin bug if it's that sensitive.

[jdemeyer]

comment:5

Can you compile the Sage library with -O0 -g just to check for a potential compiler bug? You will need to do rm -rf src/build first.

[embray]

comment:6

I'll give that a try in a bit. A compiler bug is also certainly a possibility. This is gcc 6.4.0.

[embray]

comment:7

It's not possible that there'd be anywhere in Sage where it creates Integer objects while the GIL is released, is there?

[jdemeyer]

comment:8

More generally, I think that Sage never releases the GIL. Libraries used by Sage (e.g. Numpy) might.

[embray]

comment:9

Aha! I put some code in fast_tp_dealloc to check, before returning an Integer to the pool, if there is already an entry in the pool with the same _mp_d, and raise a RuntimeError if so. And this condition first occurs in earlier test in the same module:

sage -t --warn-long 164.8 src/sage/structure/coerce_actions.pyx
**********************************************************************
File "src/sage/structure/coerce_actions.pyx", line 758, in sage.structure.coerce_actions.IntegerMulAction._call_
Failed example:
    alarm(0.5); (2^(10^7)) * P
Expected:
    Traceback (most recent call last):
    ...
    AlarmInterrupt
Got:
    RuntimeError: [fast_tp_dealloc] DUPLICATE _mp_d: 0x0x60404ebe0L!
                            (integer_pool_count: 3)
    Exception RuntimeError: RuntimeError('[fast_tp_dealloc] DUPLICATE _mp_d: 0x0x60404ebe0L!\n                        (integer_pool_count: 3)',) in 'sage.rings.integer.fast_tp_dealloc' ignored
    Traceback (most recent call last):
      File "/home/embray/src/sagemath/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 541, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/home/embray/src/sagemath/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 951, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.structure.coerce_actions.IntegerMulAction._call_[11]>", line 1, in <module>
        alarm(RealNumber('0.5')); (Integer(2)**(Integer(10)**Integer(7))) * P
    SystemError: error return without exception set

The presence of alarm() also explains the slight randomness of this error. So it seems that somewhere the allocation/deallocation of integers not safe to interruption by a signal...

[embray]

comment:10

Specifically this is inside fast_mul which is doing some pretty heavy creation and destruction of Integers. If I just run the same code manually at the prompt and hit Ctrl-C, depending on exactly where it is fast_mul, sometimes I just get a KeyboardInterrupt raised from cysignals, or sometimes my RuntimeError gets raised.

[embray]

comment:11

Two new notes:

1. I can reproduce the problem reliably on Cygwin by the following:

sage: E = EllipticCurve(GF(5), [4,0])
sage: set_random_seed(0); P = E.random_element()
sage: alarm(0.5); (2^(10^7)) * P
---------------------------------------------------------------------------
AlarmInterrupt                            Traceback (most recent call last)
<ipython-input-3-1f9f5650ad9d> in <module>()
----> 1 alarm(RealNumber('0.5')); (Integer(2)**(Integer(10)**Integer(7))) * P
...
/home/embray/src/sagemath/sage/local/lib/python2.7/site-packages/sage/rings/integer.pyx in sage.rings.integer.Integer._shift_helper (build/cythonized/sage/rings/integer.c:40438)()
   6371         # Now finally call into MPIR to do the shifting.
   6372         cdef Integer z = PY_NEW(Integer)
-> 6373         sig_on()
   6374         if n < 0:
   6375             mpz_fdiv_q_2exp(z.value, self.value, -n)

src/cysignals/signals.pyx in cysignals.signals.sig_raise_exception()

AlarmInterrupt:
sage: a = Integer(5)
sage: a
5
sage: b = Integer(1)
sage: a
1

This same process works correctly on Linux though, which is still suspicious.

2. If I remove the following lines from fast_tp_dealloc the problem appears to go away:

        # Here we free any extra memory used by the mpz_t by
        # setting it to a single limb.
        if o_mpz._mp_alloc > 10:
            _mpz_realloc(o_mpz, 1)

so it's possible also something fishy is happening with _mpz_realloc.