Opened 8 years ago
Last modified 8 years ago
#730 new bug
CTRL-C sometimes interrupts command *after* interrupt
Reported by: | Owned by: | somebody | |
---|---|---|---|
Priority: | minor | Milestone: | 4-1-0 and higher |
Component: | dontKnow | Version: | 3-1-7 |
Keywords: | Cc: |
Description
(Context: we are working in Sage to improve interrupting in Singular, but it's made difficult because Singular is so unpredictable w.r.t. interrupts)
In certain hard-to-reproduce cases, the following can happen in Singular (strace
log):
write(1, "> ", 2) = 2 read(0, "kill a;\n", 1024) = 8 write(1, "> ", 2) = 2 --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} --- write(1, "> ", 2) = 2 read(0, "\n", 1024) = 1 rt_sigaction(SIGINT, {0x52d430, [], SA_RESTORER|0x555640, 0x7f979662fbf0}, {0x52d430, [], SA_RESTORER|SA_RESTART, 0x7f979662fbf0}, 8) = 0 rt_sigreturn() = 2 read(0, "if(defined(sage32)){kill sage32;};def sage33=2+3;\n", 1024) = 50 write(2, " ? ", 5) = 5 write(2, "abort...", 8) = 8 write(2, "\n", 1) = 1 write(2, " ? ", 5) = 5 write(2, "error occurred in or before STDIN line 14: `if(defined(sage32)){kill sage32;};def sage33=2+3;`", 94) = 94 write(2, "\n", 1) = 1 write(1, "> ", 2) = 2
Here, you see that first an interrupt is received and a new prompt is displayed (making the user think that everything is ok), and afterwards the command
if(defined(sage32)){kill sage32;};def sage33=2+3;
is read, which is then "interrupted".
All this is with Singular-3-1-7 using readline as input method. It seems to be a race condition where the interrupt is received very quickly after displaying the first prompt.
If Sage sends an interrupt, is it possible to queue a dummy command afterwards to guarantee that the next command of the user is not interrupted?
Fixing this inconsistent behaviour in Singular is simply too hard for now. But we consider this a proposed feature for future Singular versions.