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

[Andreas Gustafsson]

Eli Zaretskii wrote:
> > > I don't think the loop can reasonably be inside libpthread,
> > 
> > Why not?
> 
> Because it's much more likely that Emacs has bugs that lead to
> infloops than that libpthread has such bugs.
> 
> > We are talking undefined behavior here, after all.
> 
> If libpthread was so prone to undefined behavior, it would have been
> either fixed long time ago or thrown away in favor of a more robust
> implementation.
> 
> I'm not saying such a bug in libpthread is impossible, just that it's
> much less likely than a bug in Emacs.

I never said there was a bug in libpthread.  The bug is in emacs,
which is incorrectly calling printf() from a signal handler.  Looping
is correct behavior on libpthread's part when you do that, as is any
other behavior - that's what "undefined behavior" means.

> I was under the impression that the loop happens regardless; apologies
> if I misunderstood.  But if you think it is caused by the emergency
> exit procedure, how about commenting out those printf's and running
> with the modified version for a while?  If the loops don't happen,
> then it will be another evidence in favor of your hypothesis about the
> reasons for this.
>
> In any case, if those printf's are the culprit, they are no longer
> there in the current sources of what will soon become Emacs 25.1.
> They were replaced with direct calls to 'write'.  So if we are sure
> there's no other problem that causes these loops, we can close this
> bug.

OK, to me this means that he bug has already been fixed in emacs 25.
I might as well back-port that fix to emacs 24 then, instead of just
commenting out the calls, and this bug report can be closed if no
further emacs 24 releases are planned.  If I'm still experiencing
problems after back-porting the fix or upgrading to emacs 25, I will
file separate bug reports about those.
-- 
Andreas Gustafsson, gson@gson.org