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

[Andreas Gustafsson]

Eli Zaretskii wrote:
> Is the SIGINT interrupt that shows in the backtrace the result of your
> typing C-c, or did it come from something else?

I'm not sure.  I don't recall typing C-c, but the process was sitting
there for a few hours waiting to be debugged while I attended to some
other work, and I may have done it accidentally during that time.

Also, when an emacs operation takes too long, typing C-g (sic) has
become something of a subconcious reflex after 30 years of use, so
I can't say for sure whether I have done that or not, and will likely
not be able to say the next time it happens, either.

> In any case, when this happens next, please use the procedure
> described in etc/DEBUG for locating the place where Emacs loops, and
> post that information.  Backtraces generated from an infloop
> interrupted in a random place tend to be random and don't provide
> enough information for finding out the reasons for the loop.

To be clear, whether or not emacs was in an infinite loop when it
received the SIGINT, it is in an infinite loop within libpthread now:

(gdb) define s
Type commands for definition of "s".
End with a line saying just "end".
>stepi
>x/i $pc
>end
(gdb) s
0x00007f7ff6c08440 in ?? () from /usr/lib/libpthread.so.1
=> 0x7f7ff6c08440:      callq  0x7f7ff6c083e0
(gdb) s
0x00007f7ff6c083e0 in ?? () from /usr/lib/libpthread.so.1
=> 0x7f7ff6c083e0:      pause
(gdb) s
0x00007f7ff6c083e2 in ?? () from /usr/lib/libpthread.so.1
=> 0x7f7ff6c083e2:      retq
(gdb) s
0x00007f7ff6c08445 in ?? () from /usr/lib/libpthread.so.1
=> 0x7f7ff6c08445:      sub    $0x1,%ebp
(gdb) s
0x00007f7ff6c08448 in ?? () from /usr/lib/libpthread.so.1
=> 0x7f7ff6c08448:      jne    0x7f7ff6c08440
(gdb) s
0x00007f7ff6c08440 in ?? () from /usr/lib/libpthread.so.1
=> 0x7f7ff6c08440:      callq  0x7f7ff6c083e0
(gdb) 

-- 
Andreas Gustafsson, gson@gson.org