update GAP to version 4.11, libsemigroup to 1.0.9

[dimpase]

GAP 4.11.0 and libsemigroup 1.3.1 have been released. (we pick libsemigroup 1.0.9 as the one compatible with GAP's 4.11 semigroups package)

tarball: see upstream_url fields

[mkoeppe]

Does the upgrade fix #28728?

[arojas]

Besides changes in tests output, there's only one small change needed due to the VERSION alias removal. Patch at ​https://aur.archlinux.org/cgit/aur.git/tree/sagemath-gap-4.11.patch?h=sagemath-git

I haven't tested the gap-packages update

[dimpase]

New commits:

​47c42d0	version bumps, checksums, patch removal, packages: updated names
​1b80d95	libsemigroups update

[git]

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

​f361b88

libsemigroups update

[dimpase]

sage -t --warn-long 105.7 --random-seed=0 src/sage/libs/gap/element.pyx  # 6 doctests failed
sage -t --warn-long 105.7 --random-seed=0 src/sage/libs/gap/libgap.pyx  # 1 doctest failed

something to be fixed 1st

[git]

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

​82191ca	fix conversion from gap polynomial with valence > 0
​c582e80	better syntax for libgap calls
​bbd7419	version bumps, checksums, patch removal, packages: updated names
​87c6a6b	libsemigroups update
​8429a9c	patches from Arch (cf #29314)

[git]

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

​08193ae

tagged #random tests with output depending upon gap_packages installed

[git]

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

​c90360b

one more doctest fix

[git]

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

​2121141

more robust test, so that GAP's packages don't matter

[dimpase]

there seems to be one failing doctest that is macOS-specific, in src/sage/groups/cubic_braid.py, but I still think we have to proceed (it's probably a platform-specific GAP bug).

[dimpase]

on macOS 10.15.6 with and without gap_packages installed

sage -t --warn-long 70.9 --random-seed=0 src/sage/groups/cubic_braid.py
**********************************************************************
File "src/sage/groups/cubic_braid.py", line 1454, in sage.groups.cubic_braid.CubicBraidGroup.as_matrix_group
Failed example:
    m_back = C5(m)
Exception raised:
    Traceback (most recent call last):
      File "/Users/dima/software/sagetrac-mirror/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 715, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/Users/dima/software/sagetrac-mirror/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 1139, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.groups.cubic_braid.CubicBraidGroup.as_matrix_group[4]>", line 1, in <module>
        m_back = C5(m)
      File "sage/structure/parent.pyx", line 900, in sage.structure.parent.Parent.__call__ (build/cythonized/sage/structure/parent.c:9336)
        return mor._call_(x)
      File "sage/structure/coerce_maps.pyx", line 161, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (build/cythonized/sage/structure/coerce_maps.c:4623)
        raise
      File "sage/structure/coerce_maps.pyx", line 156, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (build/cythonized/sage/structure/coerce_maps.c:4515)
        return C._element_constructor(x)
      File "/Users/dima/software/sagetrac-mirror/local/lib/python3.7/site-packages/sage/groups/cubic_braid.py", line 1314, in _element_constructor_
        return map_to.lift(x)
      File "/Users/dima/software/sagetrac-mirror/local/lib/python3.7/site-packages/sage/groups/libgap_morphism.py", line 514, in lift
        if h.gap() not in phi.Image():
      File "sage/libs/gap/element.pyx", line 656, in sage.libs.gap.element.GapElement.__contains__ (build/cythonized/sage/libs/gap/element.c:7753)
        return GAP_IN(other, self).sage()
      File "sage/libs/gap/element.pyx", line 2525, in sage.libs.gap.element.GapElement_Function.__call__ (build/cythonized/sage/libs/gap/element.c:19780)
        sig_on()
    sage.libs.gap.util.GAPError: Error, reached the pre-set memory limit
    (change it with the -o command line option)

can't reproduce this on Linux

[dimpase]

Sebastian, could you reproduce this computation in GAP? I suspect it's a "pure" GAP bug.

[arojas]

It's not macOS-specific, I've been seeing this on Arch since I updated GAP. It only happens when running the full test suite, testing only the groups/cubic_braid.py file or even the entire groups module works.

[dimpase]

Replying to arojas:

It's not macOS-specific, I've been seeing this on Arch since I updated GAP. It only happens when running the full test suite, testing only the groups/cubic_braid.py file or even the entire groups module works.

On macOS it's reproducible at Sage prompt.

[dimpase]

I'll just do

src/sage/interfaces/gap.py

@@ -277 +277 @@
     # Don't eat all address space if the user set ulimit -v
     suggested_size = min(suggested_size, vmax // 10)
     # ~220MB is the minimum for long doctests
-    suggested_size = max(suggested_size, 250 * 1024**2)
+    suggested_size = max(suggested_size, 350 * 1024**2)
     return suggested_size

this limit has not been chnaged for 7 years, so that's OK :-)

[git]

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

​f02f6e1

increase memory pool for libgap

[dimpase]

made it 400m

[dimpase]

GitHub Actions tests on ​https://github.com/sagemath/sage/pull/98

[mkoeppe]

​https://github.com/sagemath/sage/actions just needs some housekeeping - there are lots of workflowed from the WSL pull request that are no longer needed

[dimpase]

ping?

[mkoeppe]

The updated libsemigroup fails to build on the outdated platforms ubuntu-trusty, debian-jessie, linuxmint-17. This is a regression regarding platform support, but I think that's fine for an optional package (also normaliz has the same problem).

Otherwise looks fine.

[mkoeppe]

Does the upgrade fix something "critical"?

[dimpase]

it removes a lot of patches (in fact, all the patches we have for gap and gap_packages), for one, which is always good. It incorporates numerous upstream bug fixes too, and it's a bit overdue, as 4.11 was released 6 months ago.

[soehms]

Replying to dimpase:

Sebastian, could you reproduce this computation in GAP? I suspect it's a "pure" GAP bug.

Sorry, that I didn't see that earlier, since I'm on vacation until next weekend! But it seems that you've solved that already.

Do you know the reason why the domains of permutation groups of matrix groups have increased in the new version (see the differences of the doctests of permgroup.py at line 850 and 899)? On a first impression I wouldn't take that for an improvement. Anyway, I would break these long doctests lines.

Sebastian.

[vbraun]

Docbuild hangs forever on buildbots, a strace ends with

$ strace -ff ./sage --docbuild --verbose 99 --no-pdf-links all html
[...]
[pid 106971] access("/var/lib/buildbot/slave/sage_git/build/local/share/gap/pkg/resclasses-4.7.2/init.g", F_OK) = 0
[pid 106971] access("/var/lib/buildbot/slave/sage_git/build/local/share/gap/pkg/resclasses-4.7.2/read.g", F_OK) = 0
[pid 106971] access("/var/lib/buildbot/slave/sage_git/build/local/share/gap/pkg/polenta-1.3.9/doc/manual.six", F_OK) = 0
[pid 106971] access("/var/lib/buildbot/slave/sage_git/build/local/share/gap/pkg/resclasses-4.7.2/doc/manual.six", F_OK) = 0
[pid 106971] access("/var/lib/buildbot/.gap/gaprc", R_OK) = -1 ENOENT (No such file or directory)
[pid 106971] access("/var/lib/buildbot/.gap/gaprc.gz", R_OK) = -1 ENOENT (No such file or directory)
[pid 106971] access("/var/lib/buildbot/slave/sage_git/build/local/share/gap/gaprc", R_OK) = -1 ENOENT (No such file or directory)
[pid 106971] access("/var/lib/buildbot/slave/sage_git/build/local/share/gap/gaprc.gz", R_OK) = -1 ENOENT (No such file or directory)
[pid 106971] access("/var/lib/buildbot/.gap", F_OK) = -1 ENOENT (No such file or directory)
[pid 106971] open("/var/lib/buildbot/.gaprc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 106971] access("/var/lib/buildbot/.gaprc.gz", R_OK) = -1 ENOENT (No such file or directory)
[pid 106971] access("/var/lib/buildbot/.gaprc.gz.gz", R_OK) = -1 ENOENT (No such file or directory)
[pid 106971] open("/var/lib/buildbot/slave/sage_git/build/local/lib/python3.8/site-packages/sage/libs/gap/sage.gaprc", O_RDONLY) = 12
[pid 106971] read(12, "# This file is run by Sage when "..., 20000) = 567
[pid 106971] read(12, "", 20000)        = 0
[pid 106971] close(12)                  = 0
[pid 106971] rt_sigaction(SIGCHLD, {SIG_DFL, [CHLD], SA_RESTORER|SA_RESTART, 0x7f2bc20154b0}, {0x7f0bc9679880, [CHLD], SA_RESTORER|SA_RESTART, 0x7f2bc20154b0}, 8) = 0
[pid 106971] stat("/var/lib/buildbot/slave/sage_git/build/local/lib/python3.8/site-packages/sage/matrix", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
[pid 106971] stat("/var/lib/buildbot/slave/sage_git/build/local/lib/python3.8/site-packages/sage/matrix/action.cpython-38-x86_64-linux-gnu.so", {st_mode=S_IFREG|0755, st_size=1110904, ...}) = 0
[pid 106971] open("/var/lib/buildbot/slave/sage_git/build/local/lib/python3.8/site-packages/sage/matrix/action.cpython-38-x86_64-linux-gnu.so", O_RDONLY|O_CLOEXEC) = 12
[pid 106971] read(12, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300?\0\0\0\0\0\0"..., 832) = 832
[pid 106971] fstat(12, {st_mode=S_IFREG|0755, st_size=1110904, ...}) = 0
[pid 106971] mmap(NULL, 2244824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 12, 0) = 0x7f0babc8a000
[pid 106971] mprotect(0x7f0babca9000, 2093056, PROT_NONE) = 0
[pid 106971] mmap(0x7f0babea8000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 12, 0x1e000) = 0x7f0babea8000
[pid 106971] mmap(0x7f0babeae000, 216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0babeae000
[pid 106971] close(12)                  = 0
[pid 106971] mprotect(0x7f0babea8000, 4096, PROT_READ) = 0
[pid 106971] mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0babc4a000
[pid 106971] munmap(0x7f0babc4a000, 262144) = 0
[pid 106971] mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0babc4a000
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={16, 968000}, ru_stime={0, 556000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={16, 968000}, ru_stime={0, 556000}, ...}) = 0
[pid 106971] madvise(0x100004a00000, 7344128, MADV_DONTNEED) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={17, 532000}, ru_stime={0, 556000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={17, 532000}, ru_stime={0, 556000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={18, 76000}, ru_stime={0, 556000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={18, 76000}, ru_stime={0, 556000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={18, 624000}, ru_stime={0, 564000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={18, 624000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={19, 172000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={19, 172000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={19, 712000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={19, 712000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={20, 252000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={20, 252000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={20, 788000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={20, 792000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={21, 328000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={21, 328000}, ru_stime={0, 568000}, ...}) = 0
[pid 106971] getrusage(RUSAGE_SELF, {ru_utime={21, 872000}, ru_stime={0, 568000}, ...}) = 0
[... repeat ad infinitum ...]

but not when building locally. I tried to delete the content of sage.gaprc but that didn't help.

[dimpase]

Absolutely no idea what sort of fresh hell this might be.

Time to get rid of buildbots, maybe...

---

New commits:

​3564999

build/pkgs/gap_packages: Use symlinks to refer to gap's tarball

[dimpase]

could it be something like running out of file descriptors?

[vbraun]

Unlikely, it happened also on kucalc which is rather beefy

[dimpase]

OS has a hard limit on the number of them, beefy or not, and if you leak them, then god help you.

could also be some parallelisation crap. Do bildbots try to over-parallelise things, with setting MAKE to something etc?

Could also be something similar to ​https://trac.sagemath.org/ticket/30351 - which deals with a hanging docbuild on macOS - maybe this desease is now infecting buildbots too?

[vbraun]

There are multiple physical hosts, its not a resource limit (or at least one thats set up by the docbuilder)

[dimpase]

any idea at what point of docbuild it hangs?

[vbraun]

cd ../.. && sage-logger -p './sage --docbuild --no-pdf-links all html -j ' logs/dochtml.log
[dochtml] 
[dochtml] Building reference manual, first pass.
[dochtml] 
[dochtml] [reference] building [inventory]: targets for 1 source files that are out of date
[dochtml] [reference] updating environment: [new config] 1 added, 0 changed, 0 removed
[dochtml] [reference] The inventory files are in local/share/doc/sage/inventory/en/reference/references.
[dochtml] Build finished. The built documents can be found in /home/buildbot/slave/sage_git/build/local/share/doc/sage/inventory/en/reference/references
[dochtml] [spkg     ] building [inventory]: targets for 271 source files that are out of date
[dochtml] [spkg     ] updating environment: [new config] 271 added, 0 changed, 0 removed
[dochtml] [spkg     ] The inventory files are in local/share/doc/sage/inventory/en/reference/spkg.
[dochtml] Build finished. The built documents can be found in /home/buildbot/slave/sage_git/build/local/share/doc/sage/inventory/en/reference/spkg
[dochtml] [manifolds] building [inventory]: targets for 78 source files that are out of date
[dochtml] [manifolds] updating environment: [new config] 78 added, 0 changed, 0 removed
[dochtml] [manifolds] The inventory files are in local/share/doc/sage/inventory/en/reference/manifolds.
[dochtml] Build finished. The built documents can be found in /home/buildbot/slave/sage_git/build/local/share/doc/sage/inventory/en/reference/manifolds
[dochtml] [polynomia] building [inventory]: targets for 62 source files that are out of date
[dochtml] [polynomia] updating environment: [new config] 62 added, 0 changed, 0 removed
[dochtml] [polynomia] The inventory files are in local/share/doc/sage/inventory/en/reference/polynomial_rings.
[dochtml] Build finished. The built documents can be found in /home/buildbot/slave/sage_git/build/local/share/doc/sage/inventory/en/reference/polynomial_rings
[dochtml] [repl     ] building [inventory]: targets for 35 source files that are out of date
[dochtml] [repl     ] updating environment: [new config] 35 added, 0 changed, 0 removed
[dochtml] [repl     ] The inventory files are in local/share/doc/sage/inventory/en/reference/repl.
[dochtml] Build finished. The built documents can be found in /home/buildbot/slave/sage_git/build/local/share/doc/sage/inventory/en/reference/repl
[dochtml] [algebras ] building [inventory]: targets for 95 source files that are out of date
[dochtml] [algebras ] updating environment: [new config] 95 added, 0 changed, 0 removed
[dochtml] [algebras ] The inventory files are in local/share/doc/sage/inventory/en/reference/algebras.
[dochtml] Build finished. The built documents can be found in /home/buildbot/slave/sage_git/build/local/share/doc/sage/inventory/en/reference/algebras
[dochtml] [tensor_fr] building [inventory]: targets for 19 source files that are out of date
[dochtml] [tensor_fr] updating environment: [new config] 19 added, 0 changed, 0 removed
[dochtml] [tensor_fr] The inventory files are in local/share/doc/sage/inventory/en/reference/tensor_free_modules.
[dochtml] Build finished. The built documents can be found in /home/buildbot/slave/sage_git/build/local/share/doc/sage/inventory/en/reference/tensor_free_modules
[dochtml] Warning: Missing title for sage.combinat.posets.mobile
[dochtml] [combinat ] building [inventory]: targets for 378 source files that are out of date
[dochtml] [combinat ] updating environment: [new config] 378 added, 0 changed, 0 removed
command timed out: 1200 seconds without output running ['make', 'doc-html-mathjax'], attempting to kill
process killed by signal 9
program finished with exit code -1
elapsedTime=1349.554977

@mkoeppe: can you try to reproduce it on a CI build?

[dimpase]

What is the meaning of -j option in ./sage --docbuild --no-pdf-links all html -j ?

Is it documented? If it's akin to -j for make, then, hmm, all bets are off.

[dimpase]

Ah, ok, -j is for MathJax. Is MathJax locally installed?

[vbraun]

Definitely not on all buildbots...

[dimpase]

Replying to vbraun:

Definitely not on all buildbots...

does it only hang on buildbots without locally installed MathJax ?

[soehms]

Here an observation which could help:

If I checkout this ticket on top of 9.2.beta12 and do

make SAGE_SPKG="sage-spkg -o" gap_packages-clean build

then I get:

sage: B = BraidGroup(8)
Traceback (most recent call last):
...
GAPError: Error, no method found! Error, no 2nd choice method found for `InverseSameMutability' on 1 arguments

I came accross that while looking at the docbuild failure noted in #30346 (which seems to be caused by this ticket as well).

[dimpase]

Replying to soehms:

Here an observation which could help (done under WSL Ubuntu):

If I checkout this ticket on top of 9.2.beta12 and do

make SAGE_SPKG="sage-spkg -o" gap_packages-clean build

then I get:

sage: B = BraidGroup(8)
Traceback (most recent call last):
...
GAPError: Error, no method found! Error, no 2nd choice method found for `InverseSameMutability' on 1 arguments

I came accross that while looking at the docbuild failure noted in #30346 (which seems to be caused by this ticket as well).

I tried B = BraidGroup(8) on this branch, without and with gap_packages installed, and it works for me. (On Gentoo Linux - so this might be an WSL problem).

[dimpase]

to support gcc10 we need ​https://github.com/gap-packages/cohomolo/pull/25 here

[mkoeppe]

Can this upstream patch be applied to the existing gap version (4.10.2) as well? Then that should probably be done on a separate ticket

[dimpase]

added a patch needed for gap_packages on XCode 12

---

New commits:

​b0d8fc8	version bumps, checksums, patch removal, packages: updated names
​c0b35f9	libsemigroups update
​6a6c8ce	patches from Arch (cf #29314)
​3c45832	tagged #random tests with output depending upon gap_packages installed
​07968eb	one more doctest fix
​2728be6	more robust test, so that GAP's packages don't matter
​b2fa6d8	increase memory pool for libgap
​dd39f33	build/pkgs/gap_packages: Use symlinks to refer to gap's tarball
​3435c24	clang 12 (macOS XCode 12) needs extra includes

[git]

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

​ca2c40a

version bump

[git]

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

​5549ee6

fix cohomolo pkg code to allow build with gcc10

[dimpase]

added forgotten gcc-10 patch

[soehms]

Replying to dimpase:

Replying to soehms:

Here an observation which could help (done under WSL Ubuntu):

....

I tried B = BraidGroup(8) on this branch, without and with gap_packages installed, and it works for me. (On Gentoo Linux - so this might be an WSL problem).

Dima, I'm having the same problem on LinuxMint 19.1. So, its probably not a WSL issue but maybe a problem with the person in front of the computer. Can you please post how I have to build Sage after checking out the branch?

[dimpase]

Replying to soehms:

Dima, I'm having the same problem on LinuxMint 19.1. So, its probably not a WSL issue but maybe a problem with the person in front of the computer. Can you please post how I have to build Sage after checking out the branch?

1. pull the branch
2. ./sage -f gap
3. ./sage -f gap_packages # (optional)
4. make build

[soehms]

Replying to dimpase:

Replying to soehms:

Dima, I'm having the same problem on LinuxMint 19.1. So, its probably not a WSL issue but maybe a problem with the person in front of the computer. Can you please post how I have to build Sage after checking out the branch?

1. pull the branch
2. ./sage -f gap
3. ./sage -f gap_packages # (optional)
4. make build

Thank you! Unfortunately that didn't solve the problem. Is it possible that there is a dependency missing in the ticket description?

The list of doctest failures under groups I'm getting under WSL and LinuxMint looks like this:

...
sage -t --random-seed=0 src/sage/groups/braid.py  # 289 doctests failed
sage -t --random-seed=0 src/sage/groups/raag.py  # 145 doctests failed
sage -t --random-seed=0 src/sage/groups/libgap_wrapper.pyx  # 13 doctests failed
sage -t --random-seed=0 src/sage/groups/free_group.py  # Killed due to segmentation fault
sage -t --random-seed=0 src/sage/groups/finitely_presented.py  # 251 doctests failed
...

In the case of finitely_presented.py I also got longjmp error messages:

*** longjmp causes uninitialized stack frame ***: /home/sebastian/develop/sage/local/bin/python3 terminated
*** longjmp causes uninitialized stack frame ***: /home/sebastian/develop/sage/local/bin/python3 terminated

[dimpase]

1. try removing ~/.sage/gap/, or even ~/.sage/.

2. Could it be you have GAP installed systemwide, and you get an interference? Or perhaps something in your gap.ini or gaprc files, cf. ​https://www.gap-system.org/Manuals/doc/ref/chap3.html#X7FD66F977A3B02DF ?

3. Test the Sage's GAP 4.11 installation, e.g. by

   $ SAGE_CHECK=yes ./sage -f gap
   

4. Try building this branch from scratch.

[git]

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

​40a2d0f

remove old workaround from #22626

[dimpase]

Volker, could we try this again? I gather that the commit in comment:55 should change the behaviour of buildbots in comment:29, where crunch seems to happen after reading sage.gaprc (and this commit removes an overlooked GAP 4.10-specific workaround in sage.gaprc)

[soehms]

Replying to dimpase:

Thanks for the advices! Here my results:

1. try removing ~/.sage/gap/, or even ~/.sage/.

no succsess

2. Could it be you have GAP installed systemwide, and you get an interference? Or perhaps something in your gap.ini or gaprc files ...

yes, on both of the platforms there is gap 4.8.8, but I was not aware of that. I once installed Sage via apt which is an old version (8.1). My guess is that the systemwide gap came along with that (possible?).

But anyway, I have an older computer running under LinuxMint 18 without a systemwide gap installed and the bug shows there, as well, even after your latest commit. Furthermore I didn't find gap.ini and gaprc below local/share/gap.

3. Test the Sage's GAP 4.11 installation, e.g. by

   $ SAGE_CHECK=yes ./sage -f gap
   

The gap testsuite passed through successfully (in all cases).

4. Try building this branch from scratch.

On the WSL machine I build from a fresh git clone. The bug still shows.

The error output on the older machine produced back-trace information for the longjmp errors. Shall I upload a log-file?

[git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

​2ffc24a

this file should exist - leave just comments there

[dimpase]

Replying to soehms:

Replying to dimpase:

Thanks for the advices! Here my results:

1. try removing ~/.sage/gap/, or even ~/.sage/.

no succsess

2. Could it be you have GAP installed systemwide, and you get an interference? Or perhaps something in your gap.ini or gaprc files ...

yes, on both of the platforms there is gap 4.8.8, but I was not aware of that. I once installed Sage via apt which is an old version (8.1). My guess is that the systemwide gap came along with that (possible?).

Could it be that you have an old libgap too, somewhere, from Sage 8.1?

libgap and GAP share stuff under Sage, and if something came from GAP 4.8.8 then certainly there is a high chance that things break. Could you remove the old GAP and old Sage and try again?

But anyway, I have an older computer running under LinuxMint 18 without a systemwide gap installed and the bug shows there, as well, even after your latest commit. Furthermore I didn't find gap.ini and gaprc below local/share/gap.

Please make sure there no traces of other GAP installations, .gaprc etc on that other machine.

3. Test the Sage's GAP 4.11 installation, e.g. by

   $ SAGE_CHECK=yes ./sage -f gap
   

The gap testsuite passed through successfully (in all cases).

4. Try building this branch from scratch.

On the WSL machine I build from a fresh git clone. The bug still shows.

The error output on the older machine produced back-trace information for the longjmp errors. Shall I upload a log-file?

Hopefully it's just stale bits that cause this error. Could you post the linkage of libgap Python module, i.e. the output of

ldd local/lib/python3*/site-packages/sage/libs/gap/libgap.*.so

[soehms]

Replying to dimpase:

Replying to soehms:

Replying to dimpase:

......

Hopefully it's just stale bits that cause this error. Could you post the linkage of libgap Python module, i.e. the output of

ldd local/lib/python3*/site-packages/sage/libs/gap/libgap.*.so

Here the one from the LinuxMint 18

local/lib/python3.7/site-packages/sage/libs/gap/libgap.cpython-37m-x86_64-linux-gnu.so:
	linux-vdso.so.1 =>  (0x00007ffd3a776000)
	libgap.so.0 => /home/sebastian/develop/sage/local/lib/libgap.so.0 (0x00007efc33b3c000)
	libpython3.7m.so.1.0 => not found
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007efc3391f000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007efc33555000)
	libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007efc332d5000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007efc330bb000)
	libreadline.so.6 => /home/sebastian/develop/sage/local/lib/libreadline.so.6 (0x00007efc32e71000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007efc32b68000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007efc32964000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007efc32761000)
	/lib64/ld-linux-x86-64.so.2 (0x00007efc34a8c000)
	libtinfo.so.6 => /home/sebastian/develop/sage/local/lib/libtinfo.so.6 (0x00007efc32528000)
local/lib/python3.8/site-packages/sage/libs/gap/libgap.cpython-38-x86_64-linux-gnu.so:
	linux-vdso.so.1 =>  (0x00007fff44b9d000)
	libgap.so.0 => /home/sebastian/develop/sage/local/lib/libgap.so.0 (0x00007fdca3ad8000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdca38bb000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdca34f1000)
	libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fdca3271000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fdca3057000)
	libreadline.so.6 => /home/sebastian/develop/sage/local/lib/libreadline.so.6 (0x00007fdca2e0d000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdca2b04000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdca2900000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fdca26fd000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fdca4a29000)
	libtinfo.so.6 => /home/sebastian/develop/sage/local/lib/libtinfo.so.6 (0x00007fdca24c4000)

Here from WSL case

        linux-vdso.so.1 (0x00007ffff0e43000)
        libgap.so.0 => /home/sebastian/devel/sage/local/lib/libgap.so.0 (0x00007f53a2a65000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f53a2830000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f53a2430000)
        libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f53a21a0000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f53a1f80000)
        libreadline.so.7 => /lib/x86_64-linux-gnu/libreadline.so.7 (0x00007f53a1d30000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f53a1980000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f53a1770000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f53a1560000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f53a3600000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f53a1330000)

[dimpase]

Linux Mint case looks a bit funny, as you have both python 3.7 and 3.8 in one installation? Or they are different?

Could you also post the errors you get in src/sage/groups/libgap_wrapper.pyx ? (which is the root cause of the other errors, I gather)

Anyhow, I'm now testing on Linux Mint 19 (in an lxc container), let's see if this is reproducible.

[soehms]

Output of doctest of libgap_wrapper.pyx on LinuxMint? 18

[soehms]

Replying to dimpase:

Could you also post the errors you get in src/sage/groups/libgap_wrapper.pyx ? (which is the root cause of the other errors, I gather)

See the attached file!

[dimpase]

I've installed Linux Mint Tara (i.e. 19) in an xlc container, built this branch there, and ran tests - and everything worked. Here is what I have in the apt sources list

deb http://packages.linuxmint.com tara main upstream import backport
deb http://archive.ubuntu.com/ubuntu bionic main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu bionic-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu bionic-security main restricted universe multiverse

the kernel is

Linux m1 5.4.48-06434-gd868196d13af #1 SMP PREEMPT Wed Jul 29 00:32:34 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux

So it looks as if everything should run just fine - I guess something is wrong with the particular box, sorry.

[soehms]

Replying to dimpase:

So it looks as if everything should run just fine - I guess something is wrong with the particular box, sorry.

Dima, one thing common to my platforms is, that I have gap3 installed (from ​https://webusers.imj-prg.fr/~jean.michel/gap3/ according to the advices given in src/sage/interfaces/gap3.py, and I'm using it inside Sage). Did you test with gap3, as well?

BTW: removing gap 4.8.8 did not help!

[dimpase]

Replying to soehms:

Replying to dimpase:

So it looks as if everything should run just fine - I guess something is wrong with the particular box, sorry.

Dima, one thing common to my platforms is, that I have gap3 installed (from ​https://webusers.imj-prg.fr/~jean.michel/gap3/ according to the advices given in src/sage/interfaces/gap3.py, and I'm using it inside Sage). Did you test with gap3, as well?

I just tried installing gap3 experimental package and running tests, and nothing is broken for me (in Linux Mint container, too).

I don't know the advantage of following the manual instructions in src/sage/interfaces/gap3.py instead -- are there any?

Perhaps they should be marked as obsolete, or just removed. In any event, WARNING about broken pexpect there should go.

Needless to say, if you mangle your Sage installation manually in some way, then all the bets are off, we can't say that Sage has a bug then. :-)

[dimpase]

for the latter, see #30686.

[soehms]

Replying to dimpase:

Replying to soehms: ...

I just tried installing gap3 experimental package and running tests, and nothing is broken for me (in Linux Mint container, too).

Thanks for your help! In the meantime I realized that gap3 isn't the reason for my desaster, either (since against my expectation it was not present on the WSL).

I don't know the advantage of following the manual instructions in src/sage/interfaces/gap3.py instead -- are there any?

I don't know. I did that years ago when I was new to Sage, and probably didn't know it better.

Perhaps they should be marked as obsolete, or just removed. In any event, WARNING about broken pexpect there should go.

Needless to say, if you mangle your Sage installation manually in some way, then all the bets are off, we can't say that Sage has a bug then. :-)

I agree! But that was not my point. I have to fix my facilities until this ticket is released (or completely switch to working in docker containers).

[dimpase]

Replying to soehms:

do you have a particular "interesting" hardware for WSL and Mint - is it the same box? Unusual toolchain?

Could you maybe spin a WSL somewhere else and try to reproduce?

I agree! But that was not my point. I have to fix my facilities until this ticket is released (or completely switch to working in docker containers).

any test errors in src/sage/libs/gap/ ? in src/sage/groups/matrix_gps/ ? Or is your problem specifically related to free groups and finitely presented groups?

[soehms]

Replying to dimpase:

Replying to soehms:

Thanks again for your hints!

do you have a particular "interesting" hardware for WSL and Mint - is it the same box? Unusual toolchain?

The three cases above where all Lenovo ThinkPads (L560 WSL, X240 LinuxMint 19.1, L520 LinuxMint 18, all running on Intel i5). In addition I have now a fourth test case: SonyVaio (on Intel i5, as well, and LinuxMint 17.3).

On the X240 I created a Docker image for the ticket using the $SAGE_ROOT/docker/Dockerfile. The bug does not show in the corresponding container. So, I think the issue has nothing to do with the hardware.

Could you maybe spin a WSL somewhere else and try to reproduce?

I will check that out.

any test errors in src/sage/libs/gap/ ? in src/sage/groups/matrix_gps/ ? Or is your problem specifically related to free groups and finitely presented groups?

Yes:

File "src/sage/libs/gap/element.pyx", line 1335, in sage.libs.gap.element.GapElement.sage
File "src/sage/libs/gap/element.pyx", line 1336, in sage.libs.gap.element.GapElement.sage
File "src/sage/libs/gap/element.pyx", line 1338, in sage.libs.gap.element.GapElement.sage
File "src/sage/libs/gap/element.pyx", line 1347, in sage.libs.gap.element.GapElement.sage
File "src/sage/libs/gap/element.pyx", line 1348, in sage.libs.gap.element.GapElement.sage
File "src/sage/libs/gap/element.pyx", line 1350, in sage.libs.gap.element.GapElement.sage
File "src/sage/libs/gap/libgap.pyx", line 351, in sage.libs.gap.libgap.Gap._construct_matrix

sage -t --warn-long 46.3 --random-seed=0 src/sage/libs/gap/element.pyx  # 6 doctests failed
sage -t --warn-long 46.3 --random-seed=0 src/sage/libs/gap/libgap.pyx  # 1 doctest failed

Under src/sage/groups there are in sum 1182 failing doctests, 78 of them under sage.groups.matrix_gps. Free groups and finitely presented groups are just the top scores. Probably they all have the same origin.

[dimpase]

By the way, do you by any chances have any stray/old patches in build/pkgs/gap/patches or in build/pkgs/gap_packages/patches ?

Certainly, errors in src/sage/libs/gap/element.pyx and src/sage/libs/gap/libgap.pyx are the root of the problem, and should be relatively easy to debug, as it's more or less direct interaction with libgap, and well-localised - everything has to do with dealing with a GAP variable x.

So what happens if you run the stuff around line 1335 from libs/gap/element.pyx?

sage: x = libgap.Integers.Indeterminate("x")
sage: x
sage: x+1
sage: x^2
sage: p = x^2 - 2*x + 3

[vbraun]

Still hangs the buildbot

[dochtml] [algebras ] building [inventory]: targets for 95 source files that are out of date
[dochtml] [algebras ] updating environment: [new config] 95 added, 0 changed, 0 removed
[dochtml] [algebras ] The inventory files are in local/share/doc/sage/inventory/en/reference/algebras.
[dochtml] Build finished. The built documents can be found in /var/lib/buildbot/slave/sage_git/build/local/share/doc/sage/inventory/en/reference/algebras
[dochtml] [tensor_fr] building [inventory]: targets for 19 source files that are out of date
[dochtml] [tensor_fr] updating environment: [new config] 19 added, 0 changed, 0 removed
[dochtml] [tensor_fr] The inventory files are in local/share/doc/sage/inventory/en/reference/tensor_free_modules.
[dochtml] Build finished. The built documents can be found in /var/lib/buildbot/slave/sage_git/build/local/share/doc/sage/inventory/en/reference/tensor_free_modules
[dochtml] Warning: Missing title for sage.combinat.posets.mobile
[dochtml] [combinat ] building [inventory]: targets for 379 source files that are out of date
[dochtml] [combinat ] updating environment: [new config] 379 added, 0 changed, 0 removed
command timed out: 1200 seconds without output running ['make', 'doc-html-mathjax'], attempting to kill
process killed by signal 9
program finished with exit code -1
elapsedTime=1394.804628

[mkoeppe]

How about backporting the patch added for Xcode 12 and leaving the gap upgrade to the 9.3 series.

[mkoeppe]

Created #30720 for this

[soehms]

Replying to dimpase:

By the way, do you by any chances have any stray/old patches in build/pkgs/gap/patches or in build/pkgs/gap_packages/patches ?

No!

Certainly, errors in src/sage/libs/gap/element.pyx and src/sage/libs/gap/libgap.pyx are the root of the problem, and should be relatively easy to debug, as it's more or less direct interaction with libgap, and well-localised - everything has to do with dealing with a GAP variable x.

So what happens if you run the stuff around line 1335 from libs/gap/element.pyx?

sage: x = libgap.Integers.Indeterminate("x")
sage: x
sage: x+1
sage: x^2
sage: p = x^2 - 2*x + 3

The crash already occured at the addition x+1, more precisely in local/lib/python3.8/site-packages/cysignals/macros.h. It jumped to line 134 even though cysigs.sig_on_count was zero.

(gdb) n
__pyx_f_4sage_4libs_3gap_7element_10GapElement__add_ (__pyx_v_self=0x7f5e227f1840, __pyx_v_right=0x7f5e2281eb00, __pyx_skip_dispatch=<optimized out>)
    at build/cythonized/sage/libs/gap/element.c:10206
10206       __pyx_t_5 = sig_on(); if (unlikely(__pyx_t_5 == ((int)0))) __PYX_ERR(0, 1007, __pyx_L4_error)
(gdb) s
_sig_on_prejmp (message=0x0, file=0x7f5e31f0c728 "build/cythonized/sage/libs/gap/element.c", line=10206)
    at /home/sebastian/develop/sage/local/lib/python3.8/site-packages/cysignals/macros.h:117
117         cysigs.s = message;
(gdb) s
132         if (cysigs.sig_on_count > 0)
(gdb) p cysigs.sig_on_count
$2 = 0
(gdb) l
127             fprintf(stderr, "\n*** ERROR *** sig_on() with sig_on_count = %i, block_sigint = %i\n",
128                     (int)cysigs.sig_on_count, (int)cysigs.block_sigint);
129             print_backtrace();
130         }
131     #endif
132         if (cysigs.sig_on_count > 0)
133         {
134             cysigs.sig_on_count++;
135             return 1;
136         }
(gdb) s
134             cysigs.sig_on_count++;
(gdb) p cysigs.sig_on_count
$3 = 0

Therefore, I ran

sage -f cysignals
make build

and that solved the problem!

But, why did I have to do that even in the case where I build fro scratch? Anyway, thanks a lot for your patience!

[dimpase]

Replying to soehms: [...]

Therefore, I ran

sage -f cysignals
make build

and that solved the problem!

Great!

But, why did I have to do that even in the case where I build fro scratch? Anyway, thanks a lot for your patience!

Could be #30687 (with the original suject: "local/lib/python3*" must be removed) - unless you did run make distclean which removes local/ completely anyway...

[dimpase]

Replying to vbraun:

Still hangs the buildbot

Someone has to debug this somehow, I have no clue what's going on there. Could you do another strace -ff ... as in comment:29 ?

[git]

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

​2033e4a	libsemigroups update
​540d761	patches from Arch (cf #29314)
​98267a5	tagged #random tests with output depending upon gap_packages installed
​aec0937	one more doctest fix
​8a2251e	more robust test, so that GAP's packages don't matter
​d2fb822	increase memory pool for libgap
​22c7420	build/pkgs/gap_packages: Use symlinks to refer to gap's tarball
​b54ec20	version bump
​3b22dd9	remove old workaround from #22626
​649bc8d	this file should exist - leave just comments there

[dimpase]

rebased over #30720

[jhpalmieri]

The patches for gap_packages don't work:

Applying patches from ../patches...
Applying ../patches/cohomolo-gcc10.patch
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/pkg/cohomolo-1.6.7/standalone/progs.d/crp1.c b/pkg/cohomolo-1.6.7/standalone/progs.d/crp1.c
|index 3bbdc45..7df699f 100644
|--- a/pkg/cohomolo-1.6.7/standalone/progs.d/crp1.c
|+++ b/pkg/cohomolo-1.6.7/standalone/progs.d/crp1.c
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
4 out of 4 hunks ignored
can't find file to patch at input line 54
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/pkg/cohomolo-1.6.7/standalone/progs.d/nq+chfns.c b/pkg/cohomolo-1.6.7/standalone/progs.d/nq+chfns.c
|index a7396b2..658496f 100644
|--- a/pkg/cohomolo-1.6.7/standalone/progs.d/nq+chfns.c
|+++ b/pkg/cohomolo-1.6.7/standalone/progs.d/nq+chfns.c
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
4 out of 4 hunks ignored
can't find file to patch at input line 98
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/pkg/cohomolo-1.6.7/standalone/progs.d/nqmfns.c b/pkg/cohomolo-1.6.7/standalone/progs.d/nqmfns.c
|index 0896551..6841bc8 100644
|--- a/pkg/cohomolo-1.6.7/standalone/progs.d/nqmfns.c
|+++ b/pkg/cohomolo-1.6.7/standalone/progs.d/nqmfns.c
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
4 out of 4 hunks ignored
can't find file to patch at input line 135
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/pkg/cohomolo-1.6.7/standalone/progs.d/nqmp.c b/pkg/cohomolo-1.6.7/standalone/progs.d/nqmp.c
|index 01cf914..0144883 100644
|--- a/pkg/cohomolo-1.6.7/standalone/progs.d/nqmp.c
|+++ b/pkg/cohomolo-1.6.7/standalone/progs.d/nqmp.c
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
2 out of 2 hunks ignored
Error applying '../patches/cohomolo-gcc10.patch'
************************************************************************
Error applying patches
************************************************************************

[jhpalmieri]

I see: the versions are wrong. Here's a fix.

[jhpalmieri]

This (including libsemigroups and gap_packages) builds for me on OS X with Xcode 12.

---

New commits:

​47fcc16

trac 29314: fix version numbers in patches for gap_packages

[jhpalmieri]

Building the documentation, I see

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

I don't remember ever seeing this before. (The documentation build continues, but the error message was strange.)

[mkoeppe]

Then patching the failing packages in #30729 using the diff to GAP 4.11 would be a way forward

[jhpalmieri]

Doctests pass for me (with libsemigroups and gap_packages installed).

[jhpalmieri]

Replying to mkoeppe:

Then patching the failing packages in #30729 using the diff to GAP 4.11 would be a way forward

Or just merge this ticket instead.

[mkoeppe]

There are unresolved problems with this upgrade

[dimpase]

Replying to jhpalmieri:

This (including libsemigroups and gap_packages) builds for me on OS X with Xcode 12.

thanks for fixing this. What XCode 12 are you on? 12.0? 12.2?

[dimpase]

Replying to mkoeppe:

There are unresolved problems with this upgrade

and a problem I cannot debug, as it's essentially a privately run network of buildbots which (in part?) seem to hang on our damn docbuild :-(

[mkoeppe]

It does not seem realistic to get this ticket done for 9.2. So let's do #30729

[jhpalmieri]

Replying to dimpase:

Replying to jhpalmieri:

This (including libsemigroups and gap_packages) builds for me on OS X with Xcode 12.

thanks for fixing this. What XCode 12 are you on? 12.0? 12.2?

12.0.1

[soehms]

Replying to dimpase:

Replying to soehms: [...]

Therefore, I ran

sage -f cysignals
make build

and that solved the problem!

Great!

But, why did I have to do that even in the case where I build fro scratch? Anyway, thanks a lot for your patience!

Could be #30687 (with the original suject: "local/lib/python3*" must be removed) - unless you did run make distclean which removes local/ completely anyway...

It must be an independent problem. As it appears now on all of my systems (by whatever reason) I have to rebuild cysignals whenever I switch back and forth between gap 4.10 and 4.11. This is regardless of whether I merged #30687 in or not.

[dimpase]

perhaps buildbot hanging is a multithreading issue - libgap in not multithreaded, calling it from several threads is asking for trouble: ​https://github.com/gap-system/gap/issues/2893#issuecomment-707700408

[dimpase]

we should move PackageManager GAP package from gap_packages to gap - it is small and useful.

[dimpase]

The ball here is in Volker's court. I have no idea why his buildbots hang.

[slelievre]

Replying to dimpase:

we should move PackageManager GAP package from gap_packages to gap - it is small and useful.

+1 -- separate ticket or here?

[dimpase]

Replying to slelievre:

Replying to dimpase:

we should move PackageManager GAP package from gap_packages to gap - it is small and useful.

+1 -- separate ticket or here?

I'll do it here - it's still "needs review" after all.

[dimpase]

rebased over the latest beta, moved PackageManager GAP package as discussed.

[gh-tobiasdiez]

I've used this ticket in #30371, and it runs well on the github action (​https://github.com/tobiasdiez/sage/runs/1413136300?check_suite_focus=true). In particular, there was no "hanging" or multithreading problem.

The only gap related doc tests that fail are:

2020-11-17T17:27:35.4675866Z sage -t --random-seed=0 /__w/sage/sage/src/sage/interfaces/gap_workspace.py
2020-11-17T17:27:35.4676910Z **********************************************************************
2020-11-17T17:27:35.4677821Z File "/__w/sage/sage/src/sage/interfaces/gap_workspace.py", line 55, in sage.interfaces.gap_workspace.gap_workspace_file
2020-11-17T17:27:35.4681873Z Failed example:
2020-11-17T17:27:35.4683784Z     name1 = Popen([sys.executable, '-c', cmd], stdout=PIPE).communicate()[0]
2020-11-17T17:27:35.4684739Z Expected nothing
2020-11-17T17:27:35.4685235Z Got:
2020-11-17T17:27:35.4686344Z     /__w/sage/sage/src/sage/calculus/functional.py:57: DeprecationWarning: invalid escape sequence \d
2020-11-17T17:27:35.4687468Z       """
2020-11-17T17:27:39.4060681Z **********************************************************************
2020-11-17T17:27:39.4062343Z File "/__w/sage/sage/src/sage/interfaces/gap_workspace.py", line 56, in sage.interfaces.gap_workspace.gap_workspace_file
2020-11-17T17:27:39.4063371Z Failed example:
2020-11-17T17:27:39.4065030Z     name2 = Popen([sys.executable, '-c', cmd], stdout=PIPE).communicate()[0]
2020-11-17T17:27:39.4065813Z Expected nothing
2020-11-17T17:27:39.4066315Z Got:
2020-11-17T17:27:39.4067147Z     /__w/sage/sage/src/sage/calculus/functional.py:57: DeprecationWarning: invalid escape sequence \d
2020-11-17T17:27:39.4067993Z       """
2020-11-17T17:27:39.4129689Z **********************************************************************

But that could also very well be a result of the somewhat unusual setup of #30371. So from my side this looks good.

[dimpase]

Replying to gh-tobiasdiez:

I've used this ticket in #30371, and it runs well on the github action (​https://github.com/tobiasdiez/sage/runs/1413136300?check_suite_focus=true). In particular, there was no "hanging" or multithreading problem.

The only gap related doc tests that fail are:

Thanks. I can't reproduce these, they don't seem to originate from this ticket.

[mkoeppe]

New commits:

​a28138c

Merge tag '9.3.beta3' into t/29314/packages/gap411

[mkoeppe]

Looks all fine on GH Actions. (comment:25 of course still applies)