Issues with meataxe on 32bit systems (Cannot select field GF(9) in file matcore.c)

[Thierry]

Hi,

while trying to build and test Sage Debian Live 7.3, i notice some issue
with meataxe package. While doctests pass on the VM is was built on
(Pentium3 kvm-emulated), the doctests give a lot of errors when the same
binary is run on another platform (it is the same path, so it is not a
relocation issue).

All errors look like the following:

sage -t --long /opt/sagemath/sage-7.3/src/sage/algebras/group_algebra.py
**********************************************************************
File "/opt/sagemath/sage-7.3/src/sage/algebras/group_algebra.py", line 555, in sage.algebras.group_algebra.GroupAlgebra.random_element
Failed example:
GroupAlgebra(SU(2, 13), QQ).random_element(1)
Exception raised:
Traceback (most recent call last):
File "/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 499, in _run
self.compile_and_execute(example, compiler, test.globs)
File "/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 862, in compile_and_execute
exec(compiled, globs)
File "<doctest sage.algebras.group_algebra.GroupAlgebra.random_element[1]>", line 1, in <module>
GroupAlgebra(SU(Integer(2), Integer(13)), QQ).random_element(Integer(1))
File "/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/algebras/group_algebra.py", line 559, in random_element
a = self(0)
File "sage/structure/parent.pyx", line 1107, in sage.structure.parent.Parent.__call__ (/opt/sagemath/sage-7.3/src/build/cythoniz
ed/sage/structure/parent.c:9905)
return mor._call_(x)
File "sage/categories/map.pyx", line 1691, in sage.categories.map.FormalCompositeMap._call_ (/opt/sagemath/sage-7.3/src/build/cy
thonized/sage/categories/map.c:11440)
x = f._call_(x)
File "sage/categories/morphism.pyx", line 438, in sage.categories.morphism.SetMorphism._call_ (/opt/sagemath/sage-7.3/src/build/
cythonized/sage/categories/morphism.c:7603)
cpdef Element _call_(self, x):
File "sage/categories/morphism.pyx", line 457, in sage.categories.morphism.SetMorphism._call_ (/opt/sagemath/sage-7.3/src/build/
cythonized/sage/categories/morphism.c:7550)
return self._function(x)
File "/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/categories/unital_algebras.py", line 289, in from_base_ring_
from_one_basis
return self.term(self.one_basis(), r) #.
File "/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/combinat/free_module.py", line 1739, in term
return self._from_dict( {index: coeff} )
File "sage/groups/matrix_gps/group_element.pyx", line 467, in sage.groups.matrix_gps.group_element.MatrixGroupElement_gap.__hash
__ (/opt/sagemath/sage-7.3/src/build/cythonized/sage/groups/matrix_gps/group_element.c:6302)
return hash(self.matrix())
File "sage/misc/cachefunc.pyx", line 2401, in sage.misc.cachefunc.CachedMethodCallerNoArgs.__call__ (/opt/sagemath/sage-7.3/src/
build/cythonized/sage/misc/cachefunc.c:12716)
self.cache = f(self._instance)
File "sage/groups/matrix_gps/group_element.pyx", line 580, in sage.groups.matrix_gps.group_element.MatrixGroupElement_gap.matrix
(/opt/sagemath/sage-7.3/src/build/cythonized/sage/groups/matrix_gps/group_element.c:7384)
m = MS([x.sage(ring=ring) for x in entries])
File "/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/matrix/matrix_space.py", line 526, in __call__
return self.matrix(entries, coerce, copy)
File "/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/matrix/matrix_space.py", line 1483, in matrix
return MC(self, x, copy=copy, coerce=coerce)
File "sage/matrix/matrix_gfpn_dense.pyx", line 346, in sage.matrix.matrix_gfpn_dense.Matrix_gfpn_dense.__cinit__ (build/cythonized/sage/matrix/matrix_gfpn_dense.c:4471)
self.Data = MatAlloc(f, nrows, ncols)
SystemError: Cannot select field GF(169) in file matcore.c (line 130)
**********************************************************************

I do not know whether https://trac.sagemath.org/ticket/20136 will fix
this. For now, i am removing it from the list of optional pkgs to install
on SDL.

Ciao,
Thierry

[Jeroen Demeyer]

On 2016-09-21 14:42, Thierry wrote:
> Hi,
>
> while trying to build and test Sage Debian Live 7.3, i notice some issue
> with meataxe package. While doctests pass on the VM is was built on
> (Pentium3 kvm-emulated), the doctests give a lot of errors when the same
> binary is run on another platform (it is the same path, so it is not a
> relocation issue).

For the record, meataxe works fine for me on

Linux arando 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:05:16 UTC
2016 i686 i686 i686 GNU/Linux

(a physical machine, no VM)

[Thierry]

Thanks. The problem is when i run the same binary on another machine (same
kernel, same location).



> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Simon King]

Hi Thierry,

On 2016-09-21, Thierry <sage-goo...@lma.metelu.net> wrote:
> while trying to build and test Sage Debian Live 7.3, i notice some issue
> with meataxe package.

Thanks for trying!

> While doctests pass on the VM is was built on
> (Pentium3 kvm-emulated), the doctests give a lot of errors when the same
> binary is run on another platform (it is the same path, so it is not a
> relocation issue).
>
> All errors look like the following:
>
> sage -t --long /opt/sagemath/sage-7.3/src/sage/algebras/group_algebra.py
> **********************************************************************

> ...

> SystemError: Cannot select field GF(169) in file matcore.c (line 130)
> **********************************************************************

Hm. That traces back to the meataxe function FfSetField, which gives a
error when it can neither read a stored multiplication table nor create
a new one.

> I do not know whether https://trac.sagemath.org/ticket/20136 will fix
> this. For now, i am removing it from the list of optional pkgs to install
> on SDL.

A part of #20136 is related with finding the correct path to the
multiplication tables. So, perhaps it does fix it. Can you please try?

Just to make sure: Both systems are 32bit, right? Does meataxe work, if
you do *not* move the binary to a different platform but keep it on the
platform it was compiled with? Is sizeof(long) different on both
platforms? If it is different, then perhaps meataxe has sizeof(long)
hardcoded somewhere?

Best regards,
Simon

[Thierry]

Hi,

On Thu, Sep 22, 2016 at 01:00:57PM +0000, Simon King wrote:
[...]

> A part of #20136 is related with finding the correct path to the
> multiplication tables. So, perhaps it does fix it. Can you please try?

I will have a try (but it might take some time).

> Just to make sure: Both systems are 32bit, right?

Yes, though in the first case the (pentium3 emulated) processor is only
capable of 32 bit (no lm flag), while in the other cases (genuine pentium4
and genuine core2duo), while the kernel is 32bit, the proc is capable of
64bit.

> Does meataxe work, if you do *not* move the binary to a different
> platform but keep it on the platform it was compiled with?

Yes.

> Is sizeof(long) different on both platforms?

In both cases i got 4, it is almost the same kernel (3.16.0-4-586 vs
3.16.0-4-686-pae).

Ciao,
Thierry

[Simon King]

Hi Thierry,

On 2016-09-22, Thierry <sage-goo...@lma.metelu.net> wrote:
> Yes, though in the first case the (pentium3 emulated) processor is only
> capable of 32 bit (no lm flag), while in the other cases (genuine pentium4
> and genuine core2duo), while the kernel is 32bit, the proc is capable of
> 64bit.

Not sure if that can be a problem.

>> Does meataxe work, if you do *not* move the binary to a different
>> platform but keep it on the platform it was compiled with?
>
> Yes.

"Yes" for both of the two platforms?

Best regards,
Simon

[Dima Pasechnik]

Hi Thierry,

do you realise that Pentium III has been out of production for 15 years?

It does not strike me as an important issue that an emulator for this truly museum piece of hardware does not produce

binaries compatible with other, slightly less outdated, pieces of hardware...

I understand that most probably you'd like to build a binary that works on as many archs as possible.

I am not sure that the approach to use such an outdated piece is the right one; nothing gets seriously tested 

on such hardware nowadays. (E.g. I doubt that gcc is tested on Pentium III nowadays...).