Can't terminate input routine or infinite loops without corrupting Prolog session

Help!
1

Hello.

I’ve encountered some serious problems with SWI-Prolog 9.0.4-1.x64 under Windows 10 64-bit. Namely with abort after Ctrl + C, e.g. when using read_line_to_string(user_input, …). SWI-Prolog shows some strange behaviour then (it hangs, with an entering prompt without ?- or anything else, etc.).

When I use repeat(+ fail) and automatically execute it, together with read_line_to_string(user_input, …) that shall provide the escape conditions, is it normal that SWI-Prolog gets caught in an infinite loop, which I can’t terminate?

When I use read_line_to_string(user_input, …) without automatic execution and want to terminate it, I can’t without corrupting the Prolog session. When pressing Ctrl + C, then entering b, then entering the same predicate that is problematic, then pressing Ctrl + C again, then entering a and closing the application, I get Windows errors as shown in the attached images.

I’ve installed the latest Visual C++ Redistributable (https://aka.ms/vs/17/release/vc_redist.x64.exe).

SWI-Prolog_at 'abort'_1
SWI-Prolog_at 'abort'_2

2

This seems related (on Linux): ctrl-C in read leads exit from REPL · Issue #1097 · SWI-Prolog/swipl-devel · GitHub

3

Thanks for reminding on this dangling issue. That looks fixed with 9728ba8a7cc83ae3a02b71fd7684063ee0ffbff3. For me (with the above patch that could be related, but I’m not sure), swipl-win.exe (the windowed version) works almost fine for the OP’s problem. The only thing is that it does not re-prompt after an abort, but hitting RETURN it does.

Should not be normal, but completely ruling it out is also hard. Interrupts are handled synchronously and there is code that doesn’t check for interrupts for too long. On non-Windows a second Ctrl-C invokes an unsafe synchronous interrupt.

Toplevel reading and interrupts have lots of different scenarios depending on OS, type of embedding and command line editor used.