Dima Pasechnik

maybe it segfaults on `libgap.Sum(*rnd)` when `rnd==[]` ?

This also pops up on Fedora 39 with system Python 3.12, see e.g. https://groups.google.com/g/sage-release/c/oTnTrEnB3YU/m/tZiLm66ZAwAJ

But I can't reproduce this with Python 3.12.2

@sheerluck has kindly disassembled broken `element....so`, resulting from compilation of `element.c`. I report the result here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872#c12 (that is, code generation is broken, the call to `GAP_CallFunc3Args()` is formed with...

more discussion on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 seems to indicate that gcc is actually not broken, it's our code that is (missing volatile declarations). See also https://stackoverflow.com/questions/7996825/why-volatile-works-for-setjmp-longjmp If I am not mistaken, we...

See https://trofi.github.io/posts/312-the-sagemath-saga.html for a detailed analysis. Not sure whether the detail that GAP uses setjmp/longjmp to return from `GAP_CallFunc3Args()` here in the 1st place.

By the way, the Python 3.12 is only needed to produce a crash. Otherwise, we get a memory leak, as these temporary GAP objects are not cleared. ``` $ ./sage...

we should do rigorous fixing, not just an ad hoc like this. We need a stateless way to create GAP objects, which can be automatically destroyed.

Perhaps more `volatile`s have to be added, like it was done there: ``` 72e6b66b1c96 (Dima Pasechnik 2024-05-06 23:53:47 +0100 2488) cdef volatile Obj v2 ``` Compilers get more efficient in...

What GAP versions do you test with?