bug#12447: 24.1.50; Stuck in garbage collection on OS X

[Jan Djärv]

Hello.

I think this is probably the same bug as in #12326.  I.e. a timer gets added 
over and over again.
Please consider how to fix the original problem as described in 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12326#11 before removing the break 
statement.

        Jan D.

14 sep 2012 kl. 23:08 skrev Harald Hanche-Olsen <hanche@math.ntnu.no>:

> This concerns emacs built with --with-ns from trunk on OS X.
> 
> To start with the symptom: Emacs seems to freeze, and spends a lot of
> CPU time. Taking a sample with Activity monitor appears to indicate a
> very deeply nested mark_object calls; from this I conclude that the
> problem appears to happen in GC.
> 
> How to trigger the symptom: I always got it by trying to send an email
> message with a large attachment. My mail client of choice is Mew, but
> I suspect that any activity triggering garbage collection will also
> trigger the bug.
> 
> After bisecting, I come to the conclusion that this revision is to
> blame:
> 
> revno: 109470
> committer: Jan D. <jan.h.d@swipnet.se>
> branch nick: trunk
> timestamp: Mon 2012-08-06 18:09:02 +0200
> message:
>  * keyboard.c (timer_check_2): Add break so timer_check returns next timeout.
> 
> That revision only adds a single line of code. I also find that the
> bug disappears if I patch the current tip of trunk (revision 110013)
> as follows, which undoes revision 109470:
> 
> === modified file 'src/keyboard.c'
> --- src/keyboard.c    2012-09-13 02:21:28 +0000
> +++ src/keyboard.c    2012-09-14 19:12:15 +0000
> @@ -4484,7 +4484,6 @@
>           }
> 
>         nexttime = make_emacs_time (0, 0);
> -          break;
>       }
>       else
>       /* When we encounter a timer that is still waiting,
> 
> 
> I suppose the break was added for a good reason, so this is probably
> not the right thing. But it does cure the present problem.
> 
> (This bug is also discussed on the emacs-devel list, in the thread
> titled "Emacs seems awfully unstable on OS X lately".)
> 
> There seems to be a second bug, introduced later, that causes crashes
> (as opposed to hangs). I mention this because the second bug could
> interfere with attempts to work on this one. I will endeavour to track
> down the other bug as well.
> 
> - Harald