Subject: bug#12447: closed (Re: bug#12447: 24.1.50; Stuck in garbage collection on OS X)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 22 Sep 2012 13:22:02 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
12447: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12447
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#12447: 24.1.50; Stuck in garbage collection on OS X
From: Eli Zaretskii <[email-masked]>
To: Chong Yidong <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Sat, 22 Sep 2012 16:18:56 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Chong Yidong <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Fri, 21 Sep 2012 22:26:18 +0800
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> If I understand correctly, js2-mode (prior to the workaround) assumed
> >> the new behavior: it called run-with-idle-timer from inside the idle
> >> timer, with the same delay, with the intention of scheduling for the
> >> next period of idleness.
> >
> > I have no idea what js2-mode wants to do.  What I wrote above was
> > based on my limited reading of the code fragments posted to that bug.
> 
> OK, I guess your approach is fine.  Please go ahead and commit your
> patch when you're ready, and amend the docstring of run-with-idle-timer
> as Dmitry suggested.

Done in trunk revision 110138.  I'm therefore closing this bug.

Subject: 24.1.50; Stuck in garbage collection on OS X
From: Harald Hanche-Olsen <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 14 Sep 2012 23:08:19 +0200 (CEST)
List-Id: <debbugs-submit.debbugs.gnu.org>

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. <[email-masked]>
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