emacs crashes possibly related to vm

[mere user]

Hi vm friends and masters,

I have been experiencing repeated crashes on Mac-Emacs, perhaps related to vm usage, and am wondering if the following reports could lead someone to figure out what the problem might be. Specifically (see below), does anyone have an idea if a "deeply nested Lisp data structure" is created in vm and if this can be avoided? These crashes occur after a few hours of normal use, almost always during reading mail with vm. I am attaching an abbreviated backtrace when running emacs under a debugger, and and the full one (8Mb) is available at https://www.dropbox.com/s/3hg8v9ct2omc8x9/emacs-bt.txt. I am happy to try helping with the debugging given specific instructions on commands to give lldb. I am using the latest development vm.

I wrote YAMAMOTO Mitsuharu, the Emacs for mac developer, and his response is

> The backtrace shows that the stack is used up because some deeply
> nested Lisp data structure is recursively traversed in garbage
> collection (or possibly an unknown bug in the GC code). In normal OSX
> applications, the stack depth for the main thread is set to 8MiB by
> default, and Emacs slightly enlarges it to 8720000B (on 64-bit binary)
> by some formula in src/emacs.c:

> 817 long newlim;
> 818 extern size_t re_max_failures;
> 819 /* Approximate the amount regex.c needs per unit of re_max_failures. */
> 820 int ratio = 20 * sizeof (char *);
> 821 /* Then add 33% to cover the size of the smaller stacks that regex.c
> 822 successively allocates and discards, on its way to the maximum. */
> 823 ratio += ratio / 3;
> 824 /* Add in some extra to cover
> 825 what we're likely to use for other reasons. */
> 826 newlim = re_max_failures * ratio + 200000;

> Probably you can tweak the ratio value above and see if it mitigates
> the problem.

Here is the bug report itself:

------------------------------------------------------------------------
In GNU Emacs 24.3.2 (x86_64-apple-darwin11.4.2, Carbon Version 1.6.0 AppKit 1138.51)
 of 2013-11-08 on Yukikaze.local
Windowing system distributor `Apple Inc.', version 10.9.0
Configured using:
 `configure '--with-mac' '--enable-mac-app=/Users/xin/Documents/emacs-mac-port/build' '--prefix=/Users/xin/Documents/emacs-mac-port/build''

Important settings:
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Dired by name

Minor modes in effect:
  delete-selection-mode: t
  display-time-mode: t
  auto-image-file-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mac-mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:

Recent messages:
Loading .session...done
For information about GNU Emacs and the GNU system, type C-h C-a. [2 times]
ls does not support --dired; see `dired-use-ls-dired' for more details.
Quit
Move: 1 of 2
Move: 2 of 2
Move: 2 files
Deleting...done
Deleting...done
Making completion list...

Load-path shadows:
None found.

Features:
(shadow vm-reply vm-pcrisis vcard u-vm-color smtpmail w3m browse-url doc-view jka-compr image-mode w3m-hist w3m-fb w3m-ems w3m-ccl ccl w3m-favicon w3m-image w3m-proc w3m-util mairix vm-rfaddons vm-page vm-minibuf emacsbug dired-aux info view cal-china lunar solar cal-dst cal-bahai cal-islam cal-julian cal-hebrew holidays hol-loaddefs mule-util cal-move goto-addr thingatpt cal-x em-unix em-term term disp-table ehelp electric em-script em-prompt em-ls em-hist em-pred em-glob em-dirs em-cmpl em-basic em-banner em-alias esh-var esh-io esh-cmd esh-opt esh-ext esh-proc esh-arg eldoc esh-groups eshell esh-module esh-mode esh-util srecode/srt-mode semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn semantic/format srecode/template srecode/srt-wy semantic/wisent semantic/wisent/wisent semantic/ctxt srecode/ctxt semantic/tag-ls semantic/find srecode/compile srecode/dictionary srecode/table srecode/map srecode semanticdb-matlab semantic/db semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local cedet eieio-base eieio-opt help-mode speedbar sb-image ezimage dframe find-func cedet-matlab matlab derived tempo matlab-load osx-osascript message-x server url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap telnet dired-efap bbdb-vcard-export bbdb-print sendmail flyspell message mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mail-utils gmm-utils mailheader bbdb-vm vm-virtual vm-summary-faces vm-pop utf7 vm-imap vm-thread vm-mime vm-mouse vm-toolbar vm-menu vm-window vm-folder vm-crypto vm-summary vm-motion vm-undo vm-misc vm-message vm-macro bbdb-snarf mail-extr rfc822 bbdb-com mailabbrev bbdb-autoloads bbdb timezone ffap url-parse url-vars auto-capitalize dired-x cl-macs gv rect-mark preview-latex tex-site auto-loads delsel appt cus-edit wid-edit dictionary link connection icalendar diary-lib diary-loaddefs cal-menu calendar cal-loaddefs rect ediff-merg ediff-diff ediff-wind ediff-help ediff-util ediff-mult ediff-init ediff dired ispell easymenu ibuffer edmacro kmacro vm-autoloads vm-vars vm-version vm session uniquify warnings time image-file cus-start cus-load password cl tramp tramp-compat auth-source eieio byte-opt bytecomp byte-compile cconv gnus-util mm-util mail-prsvr password-cache tramp-loaddefs shell pcomplete comint ansi-color ring format-spec advice help-fns cl-lib advice-preload time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel mac-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote mac multi-tty make-network-process emacs)

An abbreviated backtrace:

Last login: Sun Dec 1 15:52:10 on ttys000
udp003015uds:~ $ lldb /Applications/Emacs.app/Contents/MacOS/Emacs
Current executable set to '/Applications/Emacs.app/Contents/MacOS/Emacs' (x86_64).
(lldb) run
Process 5425 launched: '/Applications/Emacs.app/Contents/MacOS/Emacs' (x86_64)
Process 5425 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5425 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5425 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5425 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5425 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
...
Process 5425 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
2013-12-01 15:56:54.773 Emacs[5425:d0b] -_continuousScroll is deprecated for NSScrollWheel. Please use -hasPreciseScrollingDeltas.
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
...
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM
Process 5425 stopped
* thread #1: tid = 0x484e3, 0x00000001000f61d1 Emacs`mark_object + 1073, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5f3aeff8)
    frame #0: 0x00000001000f61d1 Emacs`mark_object + 1073
Emacs`mark_object + 1073:
-> 0x1000f61d1: callq 0x1000f5da0 ; mark_object
   0x1000f61d6: movq 32(%r14), %rdi
   0x1000f61da: callq 0x1000f5da0 ; mark_object
   0x1000f61df: movl (%r14), %eax
(lldb) bt
* thread #1: tid = 0x484e3, 0x00000001000f61d1 Emacs`mark_object + 1073, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5f3aeff8)
    frame #0: 0x00000001000f61d1 Emacs`mark_object + 1073
    frame #1: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #2: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #3: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #4: 0x00000001000f62ab Emacs`mark_object + 1291
    frame #5: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #6: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #7: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #8: 0x00000001000f62ab Emacs`mark_object + 1291
    frame #9: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #10: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #11: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #12: 0x00000001000f62ab Emacs`mark_object + 1291
...
    frame #136042: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136043: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136044: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136045: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136046: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136047: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136048: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136049: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136050: 0x00000001000f5e20 Emacs`mark_object + 128
    frame #136051: 0x00000001000f61d6 Emacs`mark_object + 1078
    frame #136052: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #136053: 0x00000001000f61d6 Emacs`mark_object + 1078
    frame #136054: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #136055: 0x00000001000f61d6 Emacs`mark_object + 1078
    frame #136056: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136057: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136058: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136059: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136060: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136061: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #136062: 0x00000001000f61d6 Emacs`mark_object + 1078
    frame #136063: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136064: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136065: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136066: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136067: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136068: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #136069: 0x00000001000f61d6 Emacs`mark_object + 1078
    frame #136070: 0x00000001000f61a8 Emacs`mark_object + 1032
    frame #136071: 0x00000001000f61d6 Emacs`mark_object + 1078
    frame #136072: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136073: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136074: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136075: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136076: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136077: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136078: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136079: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136080: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136081: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136082: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136083: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136084: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136085: 0x00000001000f61df Emacs`mark_object + 1087
    frame #136086: 0x00000001000f6443 Emacs`mark_object + 1699
    frame #136087: 0x00000001000f65a9 Emacs`mark_buffer + 105
    frame #136088: 0x00000001000faffd Emacs`Fgarbage_collect + 637
    frame #136089: 0x000000010014ad63 Emacs`exec_byte_code + 1027
    frame #136090: 0x00000001001169b7 Emacs`funcall_lambda + 871
    frame #136091: 0x0000000100113968 Emacs`Ffuncall + 1160
    frame #136092: 0x000000010014b108 Emacs`exec_byte_code + 1960
    frame #136093: 0x00000001001169b7 Emacs`funcall_lambda + 871
    frame #136094: 0x0000000100113968 Emacs`Ffuncall + 1160
    frame #136095: 0x000000010014b108 Emacs`exec_byte_code + 1960
    frame #136096: 0x00000001001169b7 Emacs`funcall_lambda + 871
    frame #136097: 0x0000000100113968 Emacs`Ffuncall + 1160
    frame #136098: 0x0000000100116b5e Emacs`call1 + 30
    frame #136099: 0x0000000100131c4b Emacs`Fmapatoms + 203
    frame #136100: 0x0000000100113990 Emacs`Ffuncall + 1200
    frame #136101: 0x000000010014b108 Emacs`exec_byte_code + 1960
    frame #136102: 0x00000001001169b7 Emacs`funcall_lambda + 871
    frame #136103: 0x0000000100113968 Emacs`Ffuncall + 1160
    frame #136104: 0x000000010014b108 Emacs`exec_byte_code + 1960
    frame #136105: 0x00000001001169b7 Emacs`funcall_lambda + 871
    frame #136106: 0x0000000100113968 Emacs`Ffuncall + 1160
    frame #136107: 0x000000010014b108 Emacs`exec_byte_code + 1960
    frame #136108: 0x00000001001161d7 Emacs`eval_sub + 1463
    frame #136109: 0x00000001001152f5 Emacs`internal_catch + 213
    frame #136110: 0x000000010014bca4 Emacs`exec_byte_code + 4932
    frame #136111: 0x00000001001169b7 Emacs`funcall_lambda + 871
    frame #136112: 0x0000000100113968 Emacs`Ffuncall + 1160
    frame #136113: 0x000000010014b108 Emacs`exec_byte_code + 1960
    frame #136114: 0x00000001001169b7 Emacs`funcall_lambda + 871
    frame #136115: 0x00000001001165b3 Emacs`apply_lambda + 291
    frame #136116: 0x00000001001162f7 Emacs`eval_sub + 1751
    frame #136117: 0x0000000100111509 Emacs`Fprogn + 41
    frame #136118: 0x000000010010709e Emacs`Fsave_excursion + 62
    frame #136119: 0x0000000100115f95 Emacs`eval_sub + 885
    frame #136120: 0x0000000100116969 Emacs`funcall_lambda + 793
    frame #136121: 0x0000000100113968 Emacs`Ffuncall + 1160
    frame #136122: 0x00000001001158f6 Emacs`apply1 + 38
    frame #136123: 0x000000010010f8b9 Emacs`Fcall_interactively + 1321
    frame #136124: 0x00000001001138a4 Emacs`Ffuncall + 964
    frame #136125: 0x0000000100116b36 Emacs`call3 + 38
    frame #136126: 0x00000001000aeb12 Emacs`command_loop_1 + 1554
    frame #136127: 0x00000001001151f9 Emacs`internal_condition_case + 297
    frame #136128: 0x00000001000ae4dd Emacs`command_loop_2 + 77
    frame #136129: 0x00000001001152f5 Emacs`internal_catch + 213
    frame #136130: 0x00000001000afee2 Emacs`recursive_edit_1 + 226
    frame #136131: 0x00000001000a0b67 Emacs`Frecursive_edit + 231
    frame #136132: 0x000000010009d8b8 Emacs`main + 5208
    frame #136133: 0x0000000100002554 Emacs`start + 52
(lldb) exit
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] y
udp003015uds:~ $
------------------------------------------------------------------------

[Uday Reddy (reddyuday)]

Indeed, Emacs 24.3 crashed for me quite often on Windows. So, I haven't
switched to it. I am still using Emacs 24.2.

Uday

[mere user (emacs-user)]

interesting... does it crash for you with a similar bug characteristics?
 the implication of YAMAMOTO Mitsuharu's message seemed to be that this is
a vm problem...

On Mon, Dec 2, 2013 at 10:49 AM, Uday Reddy <email address hidden> wrote:

> Indeed, Emacs 24.3 crashed for me quite often on Windows. So, I haven't
> switched to it. I am still using Emacs 24.2.
>
> Uday
>
>

[Uday Reddy (reddyuday)]

No, Mitsuharu's message seems to say that it might be a bug in the "GC
code", meaning the garbage collector of Emacs. VM does create "deeply
nested data structures". It does them for parsing MIME messages and for
keeping track of message threads. How deep these data structures might be
will depend on the mail folder you have. Such data structures are also
created by some of the vm-*-debug flags. So, if you have set any such flags
for your VM, please turn them off and see if that helps.

Uday

[mere user (emacs-user)]

Thanks Uday,

is the "deeply nested structure" that vm is expected to create consistent
with the huge backtrace at
https://www.dropbox.com/s/3hg8v9ct2omc8x9/emacs-bt.txt given a folder of
some 15,000 messages? you are right that he said one may need to change
the GC code by adjusting the ratio parameter etc. I guess I misinterpreted
that to mean that the lisp structure formed by vm is so deeply nested that
it may be due to a bug. In any case, I wonder if changing that GC ratio
might indeed help. I've given up on compiling emacs myself since I started
using his version which is much better than many others I tried on the Mac.
 I don't have those debug flags on.

I wasn't sure if you are seeing the same crash under windows for 24.3, if
so, I could report this to the general emacs-bug mailing list...

Eli

On Mon, Dec 2, 2013 at 12:32 PM, Uday Reddy <email address hidden> wrote:

> No, Mitsuharu's message seems to say that it might be a bug in the "GC
> code", meaning the garbage collector of Emacs. VM does create "deeply
> nested data structures". It does them for parsing MIME messages and for
> keeping track of message threads. How deep these data structures might be
> will depend on the mail folder you have. Such data structures are also
> created by some of the vm-*-debug flags. So, if you have set any such
> flags
> for your VM, please turn them off and see if that helps.
>
> Uday
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1256783
>
> Title:
> emacs crashes possibly related to vm
>
> Status in VM (View Mail) for Emacs:
> New
>
> Bug description:
> Hi vm friends and masters,
>
> I have been experiencing repeated crashes on Mac-Emacs, perhaps
> related to vm usage, and am wondering if the following reports could
> lead someone to figure out what the problem might be. Specifically
> (see below), does anyone have an idea if a "deeply nested Lisp data
> structure" is created in vm and if this can be avoided? These crashes
> occur after a few hours of normal use, almost always during reading
> mail with vm. I am attaching an abbreviated backtrace when running
> emacs under a debugger, and and the full one (8Mb) is available at
> https://www.dropbox.com/s/3hg8v9ct2omc8x9/emacs-bt.txt. I am happy to
> try helping with the debugging given specific instructions on commands
> to give lldb. I am using the latest development vm.
>
> I wrote YAMAMOTO Mitsuharu, the Emacs for mac developer, and his
> response is
>
> > The backtrace shows that the stack is used up because some deeply
> > nested Lisp data structure is recursively traversed in garbage
> > collection (or possibly an unknown bug in the GC code). In normal OSX
> > applications, the stack depth for the main thread is set to 8MiB by
> > default, and Emacs slightly enlarges it to 8720000B (on 64-bit binary)
> > by some formula in src/emacs.c:
>
> > 817 long newlim;
> > 818 extern size_t re_max_failures;
> > 819 /* Approximate the amount regex.c needs per unit of
> re_max_failures. */
> > 820 ...

[mere user (emacs-user)]

Hi Uday, welcome back. this crash is fixed for me by the following patch
which makes newlim twice as large. I wasnt able to make the emacs
developers implement this in the distribution, so am compiling myself...

      ratio += ratio / 3;
      /* Add in some extra to cover
 what we're likely to use for other reasons. [FIX: added (...)*2] */
      newlim = (re_max_failures * ratio + 200000)*2;

On Wed, Oct 29, 2014 at 6:53 PM, Uday Reddy <email address hidden> wrote:

> ** Changed in: vm
> Status: New => Incomplete
>
> ** Changed in: vm
> Importance: Undecided => High
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1256783
>
> Title:
> emacs crashes possibly related to vm
>
> Status in VM (View Mail) for Emacs:
> Incomplete
>
> Bug description:
> Hi vm friends and masters,
>
> I have been experiencing repeated crashes on Mac-Emacs, perhaps
> related to vm usage, and am wondering if the following reports could
> lead someone to figure out what the problem might be. Specifically
> (see below), does anyone have an idea if a "deeply nested Lisp data
> structure" is created in vm and if this can be avoided? These crashes
> occur after a few hours of normal use, almost always during reading
> mail with vm. I am attaching an abbreviated backtrace when running
> emacs under a debugger, and and the full one (8Mb) is available at
> https://www.dropbox.com/s/3hg8v9ct2omc8x9/emacs-bt.txt. I am happy to
> try helping with the debugging given specific instructions on commands
> to give lldb. I am using the latest development vm.
>
> I wrote YAMAMOTO Mitsuharu, the Emacs for mac developer, and his
> response is
>
> > The backtrace shows that the stack is used up because some deeply
> > nested Lisp data structure is recursively traversed in garbage
> > collection (or possibly an unknown bug in the GC code). In normal OSX
> > applications, the stack depth for the main thread is set to 8MiB by
> > default, and Emacs slightly enlarges it to 8720000B (on 64-bit binary)
> > by some formula in src/emacs.c:
>
> > 817 long newlim;
> > 818 extern size_t re_max_failures;
> > 819 /* Approximate the amount regex.c needs per unit of
> re_max_failures. */
> > 820 int ratio = 20 * sizeof (char *);
> > 821 /* Then add 33% to cover the size of the smaller
> stacks that regex.c
> > 822 successively allocates and discards, on its way
> to the maximum. */
> > 823 ratio += ratio / 3;
> > 824 /* Add in some extra to cover
> > 825 what we're likely to use for other reasons. */
> > 826 newlim = re_max_failures * ratio + 200000;
>
> > Probably you can tweak the ratio value above and see if it mitigates
> > the problem.
>
> Here is the bug report itself:
>
> ------------------------------------------------------------------------
> In GNU Emacs 24.3.2 (x86_64-apple-darwin11.4.2, Carbon Version 1.6.0
> AppKit 1138.51)
> of 2013-11-08 on Yukikaze.local
> Windowin...