bug#22790: 24.5; Infinite loop involving malloc called from signal handler

[Andreas Gustafsson <gson@gson.org>]

Eli Zaretskii wrote:
> Is this a GUI session or a text-mode terminal (a.k.a. "TTY") session?

This is a TTY session.

> In any case, this code is run as part of the so-called "emergency
> escape", when you type C-g more than once while Emacs is busy doing
> something that cannot be interrupted.  In that situation, we are way
> past the point where invoking undefined behavior is of any concern,
> because the only thing we can do then is auto-save and commit
> suicide.

Not necessarily - there is also the option of continuing what emacs
was doing, which is what I would have done, by answering both the
"Auto-save?" and "Abort (and dump core)?" prompts with "no", if those
prompts had actually appeared.  But they didn't, because emacs entered
an infinite loop trying to print them.

> You need to use "finish", not "step" or "stepi".

I will try that the next time the lockup happens, but I'm quite sure
it won't do anything useful.

> I don't think the loop can reasonably be inside libpthread,

Why not?  We are talking undefined behavior here, after all.  If you
find looping in libpthread surprising, just wait until the nasal
demons appear :)  It could be something as simple as trying to acquire
a spinlock that was already held when the signal occurred.

> so you should try
> getting back to the Emacs application code and out of calls to library
> functions.  Typing "finish" repeatedly until you are in some Emacs
> code is the way to achieve that.

It won't be able do that since it's in an infinite loop inside
libpthread.

> But this should be done without
> typing C-g first, because otherwise you might be forcibly taken out of
> the loop, and there's no easy way to return there.
> 
> And I still don't understand why the SIGINT handler is in the
> picture.  Did you type C-g when this lockup happened?

As I said, I probably did type C-g, and may well have done so more
than once, because I have been conditioned to do that reflexively by
decades of emacs use.  I'm not realistically going to be able to
unlearn that reflex.  The only way I'd be able to stop sending emacs
SIGINTs would be to hack the code to disable C-g as the interrupt
character in the tty settings.

> > Even if you consider the backtrace to be suspect, code inspection
> > should suffice to show that the line
> > 
> >           printf ("Auto-save? (y or n) ");
> > 
> > in src/keyboard.c can be executed from a signal handler.
> 
> Indeed, it can.  But I don't think this is the reason for the problem
> you are describing.  That code cannot be entered unless you type C-g
> twice or more in a TTY session while Emacs is already in some
> un-interruptible loop or system call.  It is that loop or system call
> that we need to identify in order to fix this problem.

As far as I'm concerned, this bug report is specifically about what
happens after the SIGINT, not what happened before it.  For some
reason, emacs was unresponsive, which probably caused me to
reflexively hit control-g.  The lack of responsiveness is not
necessarily a bug - emacs may just be slow due to the size of the
files being edited, or paging, or whatever.  But entering an infinite
loop when I hit control-g, causing the loss of unsaved data and giving
me no option to continue, is definitely a bug.

>  . Emacs was running some byte code
>  . that byte code tried to read from the minibuffer, probably after
>    asking some question or prompting for some input
>  . as part of that prompt, Emacs attempted to auto-save modified
>    buffers
>  . the auto-save attempt signaled an error
>  . Emacs wanted to display the error message, and called malloc
>  . then somehow SIGINT was delivered
> 
> Does this match what you were doing?

Presumably; I don't recall the specifics.

> Any reason why auto-saving could
> fail (some filesystem that could be off-line, for example)?

The only mounted filesystem was a local hard disk, and there were no
disk errors in the system log.  Could the auto-save have failed due to
interruption by yet another (earlier) control-g?

> And where did that SIGINT come from?

Presumably from deep inside the subconscious parts of my brain :)
-- 
Andreas Gustafsson, gson@gson.org