LibGAP exits when out of memory and takes Sage with it

[vbraun]

The original example is no longer valid as of Sage 8.2-beta6. The following works nicely and the reason for why it was not working for Sage 5 and 6 was apparently never found.

This is correct and expected behaviour:

sage: G=FreeGroup(2)
sage: G.inject_variables()                                                                                                                          
sage: H=G.quotient([x0*x1^2])                                                                                                                       
sage: H.as_permutation_group()
Defining x0, x1
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-2-2fcc9750489e> in <module>()
      2 G.inject_variables()
      3 H=G.quotient([x0*x1**Integer(2)])
----> 4 H.as_permutation_group()

/home/vit/bin/sage-dev/local/lib/python2.7/site-packages/sage/groups/finitely_presented.pyc in as_permutation_group(self, limit)
   1008                 coset_table = self.gap().CosetTable(trivial_subgroup).sage()
   1009             except ValueError:
-> 1010                 raise ValueError('Coset enumeration exceeded limit, is the group finite?')
   1011         from sage.combinat.permutation import Permutation
   1012         from sage.groups.perm_gps.permgroup import PermutationGroup

ValueError: Coset enumeration exceeded limit, is the group finite?

But the problem persists in some form as the following (real life) example shows.

sage: k = 3
sage: p = 18
sage: d = 2*p/(p-6)
sage: l = 2*p*k/(p*k-2*k-2*p)
sage: F.<J,P,R1,R2> = FreeGroup()
sage: G = F / [J^3, P^(3*d), R1^p, R2^p, (F([-2,1]))^k, (F([4,3,1]))^l, F([-4,2,3,-2]), F([-4,1,3,-1]), F([-2,3,4])]
sage: k = G.rewriting_system()
sage: x = k.reduce(P^8)
sage: y = k.reduce(G([-4,2,3]))
sage: t = k.reduce(x*y)
sage: t == G.one()
gap: cannot extend the workspace any more!
vit@HP-EliteBook-8460p:~/bin/sage-dev$ 

Sage should gracefully recover from errors and crashes of external libraries. (Moreover, the notebook interface doesn't give you any clue as to what went wrong. In this case you don't even know that it was GAP who caused the crash.)

Depends on #22626

Component: group theory

Keywords: gap libgap

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

[vbraun]

comment:1

Actually this is in Sage-5.11.beta1 which still has libgap-4.5.7. Something in Sage changed, not libgap.

[vit-tucek]

comment:6

For Sage 8.2-beta6 I get nice error exception.

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-2-599244da5541> in <module>()
      2 G.inject_variables()
      3 H=G.quotient([x0*x1**Integer(2)])
----> 4 H.as_permutation_group()

/home/vit/bin/sage-dev/local/lib/python2.7/site-packages/sage/groups/finitely_presented.pyc in as_permutation_group(self, limit)
   1008                 coset_table = self.gap().CosetTable(trivial_subgroup).sage()
   1009             except ValueError:
-> 1010                 raise ValueError('Coset enumeration exceeded limit, is the group finite?')
   1011         from sage.combinat.permutation import Permutation
   1012         from sage.groups.perm_gps.permgroup import PermutationGroup

ValueError: Coset enumeration exceeded limit, is the group finite?

But checking for equality in a finitely presented group can still lead to the error described here.

k = 3
p = 18
d = 2*p/(p-6)
l = 2*p*k/(p*k-2*k-2*p)
F.<J,P,R1,R2>=FreeGroup()
G = F / [J^3, P^(3*d), R1^p, R2^p, (F([-2,1]))^k, (F([4,3,1]))^l, F([-4,2,3,-2]), F([-4,1,3,-1]), F([-2,3,4])]
k = G.rewriting_system()
x = k.reduce(P^8)
y = k.reduce(G([-4,2,3]))
t = k.reduce(x*y)
t == G.one()

[dimpase]

comment:7

Checking for equality is undesideable, GAP does try coset enumeration. I suppose you are saying Sage should recover gracefully from this. It is hard as GAP manages memory itself, and crashes.

[vit-tucek]

comment:8

Yes, that's what I am saying. Whatever GAP does it shouldn't take Sage with it.

[jdemeyer]

comment:9

Replying to @vit-tucek:

the error described here.

Details please. Can you update the ticket description?

[vit-tucek]

Changed keywords from none to gap

[jdemeyer]

comment:11

This ticket is something that should be fixed after the GAP + libGAP convergence. Once GAP == libGAP has a proper error handler, this should be easy to fix.

[slel]

comment:12

Replying to @jdemeyer:

This ticket is something that should be fixed after the GAP + libGAP convergence.
Once GAP == libGAP has a proper error handler, this should be easy to fix.

Marking #22626 as a dependency to reflect that.

[slel]

Dependencies: #22626

[embray]

comment:13

This is likely OBE but it would be good to double-check what happens in this case with the new implementation.

[embray]

comment:14

It seems that I get a segmentation fault, which is to be expected. But at least it's caught by cysignals and raised as a Python exception and everything seems to recover fine. So I think that's what we want here? I'm not sure that there's a better solution.

[embray]

comment:15

I guess at the very least the Sage code for this equality comparison should catch the exception and do something more user-friendly with it.

[embray]

comment:17

With gappy this example results in:

GAPError: Error, reached the pre-set memory limit
(change it with the -o command line option)

But there is not actually a way to change the pre-set memory limit through the libgap/gappy interface. Of course, this needs to be done before initializing the GAP interpreter.

But according to the GAP docs for -o:

If more than this amount is required during the GAP session, GAP prints an error message and enters a break loop. In that case you can enter return; which implicitly doubles the amount given with this option.

Apparently this doesn't happen with libgap/gappy since they do not enter the break loop. I'll have to figure out where exactly in GAP this is implemented and see if we can reproduce that functionality. I think it should just happen automatically, but with a warning.

[embray]

comment:18

Apparently this doubling just happens automatically when the allocator notices that it's trying to allocate more than the limit. At this point it breaks into the error loop, and if you return; it will just continue allowing the larger allocation to proceed. This might be new functionality in GAP since this ticket was first reported 8 years ago.

From the libgap/gappy perspective this means you can just repeat the same operation and have more memory allowed for it. However, it seems to take forever in this case...

I still think maybe we could catch this specific error and reproduce it as a warning (cypari2 does something similar when it needs to extend PARI's workspace).

[embray]

Changed keywords from gap to gap libgap

[dimpase]

comment:20

cf #34041 for the current state of affairs with this.