Open fingolfin opened 1 week ago
I get the same error when calling GAP.Globals.TestDirectory
, but I cannot reproduce the immediate crash when I call GAP.prompt()
afterwards. However, trying to compute something at the GAP prompt then yields a segmentation fault.
And also calling `GAP.Globals.TestDirectory
twice at the Julia prompt yields a reproducible crash.
This problem should also affect the idea to run the JuliaInterface tests from Julia (see #1005), since quite a few GAP errors are tested there.
Indeed. But it also suggests that long-term, once this issue here is fixed, we probably want to also run those tests "directly in the current session" to verify the crash is gone.
Tried to run the GAP test suite in Julia. This failed because it includes testing errors and we hijack them (so the code in GAP's
Test
which also "hijacks" error handling has no chance of running - here the very limited error handling model in GAP bites us, unlike try/catch in Julia there is no proper nesting mechanism... perhaps we could at least deal with this particular use case inTest
, but that's a separate question for the future).Anyway, after this I thought "maybe it works from a GAP prompt", so I launched one... and it crashes. Presumably because a bunch of state is not reset when we yank control away from
Test
/RunTests
/READ_STREAM_LOOP
:Look at
READ_STREAM_LOOP
it does this among other things:Note that pointers to the
input
andoutput
stack variables are being recorded inside GAP's printing system, in two global variables.When we then take over the control flow via a
longjmp
and return to Julia, those global variables are never reset.We could certainly reset them "manually" in our Julia error handler. But I worry what else might be left in a bad state... this certainly is among the worst kind, though.