Possible infinite recursion in PRINT_OR_APPEND_TO_FILE_OR_STREAM

[embray]

If a stream that is being used to print errors cannot be opened (e.g. an error elsewhere prevents streams from being closed properly) this can result in an infinite recursion when reporting that error.

The specific problem is in the error handling logic here:

gap/src/streams.c

Line 799 in efd3626

i = OpenOutputStream(destination);

If an ErrorQuit (for example) occurs elsewhere, and the stream assigned to ERROR_OUTPUT cannot be opened for whatever reason, this results in another call to ErrorQuit with the same broken stream assigned and so on. Perhaps this should do something else: Try to open *errout* as a last resort, Panic(), etc.

[markuspf]

See #2487

[embray]

Yes, much of the discussion there is relevant here as well, although the exact issue here I think is not providing an appropriate fallback when we're trying to print error messages from within the error handler, and we can't open the specified stream.

[fingolfin]

I believe we resolved this some time ago (and the fixes are already in GAP 4.11). If you still can trigger an issue and/or believe there is one based on reading the code, please don't hesitate to reopen this and/or file a new issue.

[embray]

I can believe it's been fixed but I'm not sure since the code I originally implicated hasn't been updated, but it might be dealt with elsewhere. I admit I don't recall how the issue was originally triggered. It might have shown up while developing the workaround I had to add for the Python libgap interface to capture error output: https://gitlab.com/sagemath/sage/-/blob/1e728ac0d36514f52871268588d38fe1392a5e5a/src/sage/libs/gap/util.pyx#L198

[fingolfin]

There is a new dedicated function for opening errout in src/error.c with fallbacks in case there is an error doing so. See

gap/src/error.c

Line 58 in 9723019

UInt OpenErrorOutput( void )

[embray]

I see, that definitely helps! 👍