OverflowErrors in TripleDictEraser

[jdemeyer]

With the new doctesting framework (#12415), I sometimes see errors like

sage -t --long devel/sage/sage/combinat/sf/sfa.py
**********************************************************************
File "devel/sage/sage/combinat/sf/sfa.py", line 388, in sage.combinat.sf.sfa.is_SymmetricFunctionAlgebra
Failed example:
    is_SymmetricFunctionAlgebra(SymmetricFunctions(FractionField(QQ['q','t'])).macdonald().P())
Expected:
    True
Got:
    Exception OverflowError: 'long int too large to convert to int' in <sage.structure.coerce_dict.TripleDictEraser object at 0x9531b3c> ignored
    True
**********************************************************************

on 32-bit systems.

These appear randomly non-reproducibly in doctests.

Depends on #13387

CC: @simon-king-jena @nbruin

Component: coercion

Author: Jeroen Demeyer

Reviewer: Simon King

Merged: sage-5.8.rc0

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

[simon-king-jena]

comment:2

There is a comment

# A note about how to store "id" keys in python structures:
#
# In python a "pointer length integer" (size_t) normally, is encoded
# as a *signed* integer, of type Py_ssize_t. This has an advantage in that
# if the value gets encoded as a *python integer* it can do so in a sign-preserving
# way and still make use of all the bits that python offers to store (small) integers.
#
# There is one place where we have to be careful about signs:
# Our hash values most naturally live in Py_ssize_t. We convert those into
# an index into our bucket list by taking the hash modulo the number of buckets.
# However, the modulo operator in C preserves the sign of the number we take the
# modulus of, which is not what we want.
# The solution is to always do
# (<size_t) h)% modulus
# to ensure we're doing an unsigned modulus.

Could it be that this is relevant here?

Is it really safe to do

        cdef Py_ssize_t k1,k2,k3
        cdef int offset
        k1,k2,k3,offset = r.key
        cdef Py_ssize_t h = (k1 + 13*k2 ^ 503*k3)
        PyList_GET_ITEM(buckets, (<size_t>h) % PyList_GET_SIZE(buckets))

?

Yes, we need to care about the sign. But we also have

 Py_ssize_t PyList_GET_SIZE(object list)
 PyObject* PyList_GET_ITEM(object list, Py_ssize_t i)

(hence, the modulus is Py_ssize_t, and the result will be translated into Py_ssize_t, too)

I am afraid I have no 32 bit machine to test.

[simon-king-jena]

comment:3

PS: Note the discussion that we had on #715 on that matter.

Is there a reason why we use ssize_t and not size_t?

[jdemeyer]

comment:4

Any idea on how to debug this? The problem is that currently we have no idea where this exception is generated.

[simon-king-jena]

comment:5

Google seems to tell me that one should use size_t and not ssize_t here anyway. Not sure though.

Nils, do you think it could help to consistently replace ssize_t and Py_ssize_t by size_t?

[simon-king-jena]

comment:6

Replying to @jdemeyer:

Any idea on how to debug this? The problem is that currently we have no idea where this exception is generated.

Sage's debug version?

[jdemeyer]

comment:7

Replying to @simon-king-jena:

        k1,k2,k3,offset = r.key

This line might be problematic if there is no guarantee that the components of r.key fit in the respective types (Py_ssize_t, Py_ssize_t, Py_ssize_t, int).

[jdemeyer]

comment:8

Replying to @simon-king-jena:

Sage's debug version?

Would it really give more information about where the exception is generated?

[simon-king-jena]

comment:9

Replying to @jdemeyer:

Replying to @simon-king-jena:

Sage's debug version?

Would it really give more information about where the exception is generated?

I thought that this is the point of a debug version? Is there an environment variable similar to MALLOC_CHECK_ that makes the program segfault on an overflow error, so that one could then analyse the problem using gdb?