Re: [BUG] queueing_enabled grows infinitely when in .recursive-edit

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 3, 11:18am, Peter Stephenson wrote:
}
} Here are some missing unqueue_signals() (this was quite boring, by the
} way, just in case you were thinking "wow, wish I'd done that").

Actually I was thinking "Thank you, I expected to need to do that."

} Most of these look minor but the one in execpline() looks like it could
} be hairy because most things in execpline() are hairy.

Fixing all of these is valuable/necessary, of course; but or purposes of
this specific bug report we can discount any that had an error message
nearby, because no such errors were displayed.  It also doesn't have
anything to do with history, sourcing files, or prompts, and I wasn't
using heap validation.  That narrows it down to these:

} diff --git a/Src/exec.c b/Src/exec.c
} index a429428..9890286 100644
} --- a/Src/exec.c
} +++ b/Src/exec.c
} @@ -1795,6 +1795,8 @@ execpline(Estate state, wordcode slcode, int how, int last1)
}  		deletejob(jn, 0);
}  	    thisjob = pj;
}  	}
} +	else
} +	    unqueue_signals();
}  	if ((slflags & WC_SUBLIST_NOT) && !errflag)
}  	    lastval = !lastval;
}      }
} @@ -5556,6 +5558,7 @@ runshfunc(Eprog prog, FuncWrap wrap, char *name)
}  	if (!cont) {
}  	    if (ou)
}  		zfree(ou, ouu);
} +	    unqueue_signals();
}  	    return;
}  	}
}  	wrap = wrap->next;

It's quite possible that both of these were in play, because the
restore_queue_signals() debugging that I tried reported queueing_enabled
to be 2 when it was expected to be 0 even in cases where it did not then
continue growing.

I will clean up that additional debugging for signals.h to make it
suitable for commit, so that we have a better chance of catching these
problems in new code.