GNU bug report logs -
#12447
24.1.50; Stuck in garbage collection on OS X
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 12447 <at> debbugs.gnu.org.
--
12447: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12447
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> From: Chong Yidong <cyd <at> gnu.org>
> Cc: dgutov <at> yandex.ru, hanche <at> math.ntnu.no, 12447 <at> debbugs.gnu.org
> Date: Fri, 21 Sep 2012 22:26:18 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> 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.
[Message part 3 (message/rfc822, inline)]
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 <at> 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
This bug report was last modified 12 years and 247 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.