--- Begin Message ---
|
Subject: |
24.1.50; Stuck in garbage collection on OS X |
|
Date: |
Fri, 14 Sep 2012 23:08:19 +0200 (CEST) |
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. <address@hidden>
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#12447: 24.1.50; Stuck in garbage collection on OS X |
|
Date: |
Sat, 22 Sep 2012 16:18:56 +0300 |
> From: Chong Yidong <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Fri, 21 Sep 2012 22:26:18 +0800
>
> Eli Zaretskii <address@hidden> 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.
--- End Message ---