From unknown Tue Jun 17 03:38:05 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#16039 <16039@debbugs.gnu.org> To: bug#16039 <16039@debbugs.gnu.org> Subject: Status: repeated emacs crashes (in GC?) Reply-To: bug#16039 <16039@debbugs.gnu.org> Date: Tue, 17 Jun 2025 10:38:05 +0000 retitle 16039 repeated emacs crashes (in GC?) reassign 16039 emacs submitter 16039 emacs user severity 16039 normal tag 16039 fixed thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 03 09:56:24 2013 Received: (at submit) by debbugs.gnu.org; 3 Dec 2013 14:56:24 +0000 Received: from localhost ([127.0.0.1]:56045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnrOf-0007Sp-9A for submit@debbugs.gnu.org; Tue, 03 Dec 2013 09:56:23 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45762) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnrOX-0007S2-Gw for submit@debbugs.gnu.org; Tue, 03 Dec 2013 09:56:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnrOL-0002AY-6i for submit@debbugs.gnu.org; Tue, 03 Dec 2013 09:56:08 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:45673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnrOL-0002AP-2Z for submit@debbugs.gnu.org; Tue, 03 Dec 2013 09:56:01 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnrOD-0002eu-Cq for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 09:56:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnrO5-00028v-FC for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 09:55:53 -0500 Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:34419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnrO4-00028b-VP for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 09:55:45 -0500 Received: by mail-wi0-f180.google.com with SMTP id hn9so2241430wib.7 for ; Tue, 03 Dec 2013 06:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=n0uovfoenALecFjUiiDJW3d/5sinPfPjE7NHq+2a394=; b=kwXXShH9pX2ZelxZJ1B+l91WAM2olXtQMlk4eVVR/aMEuBaggC1wiES+CL/jR1kZp+ 8pgf+dE+29vaaPlS0BUKjXF1A1yxdTl5JDOQ1JXEcn2UiAHzhVYf+GXdpe42G38cVb2y ldA2d7uj8HOdIGnwXmFoHoE6HBB7gpduyAQDjYDSz+Eajv6n69F1rtnrwD4kf+rLqtkr cEWuqL2SBVvezL/wipNwVqa1Pn+7s12ruWpgzy584tLwax64DHvYlsaAN8xVM+Z+tROz yOtalLj9TS9Hga6ddSmXRCjXmQFOs8GmIh5uQB07jiIFX+TJWprXekcwJ/MeYXNFU1Z0 4/8A== MIME-Version: 1.0 X-Received: by 10.180.106.200 with SMTP id gw8mr2859389wib.50.1386082543484; Tue, 03 Dec 2013 06:55:43 -0800 (PST) Received: by 10.216.47.129 with HTTP; Tue, 3 Dec 2013 06:55:43 -0800 (PST) Date: Tue, 3 Dec 2013 16:55:43 +0200 Message-ID: Subject: repeated emacs crashes (in GC?) From: emacs user To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary=e89a8f234b55a246a304eca27d87 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --e89a8f234b55a246a304eca27d87 Content-Type: text/plain; charset=ISO-8859-1 Dear Emacs masters, I have been experiencing repeated crashes on Emacs, and am wondering if the following reports could lead someone to figure out what the problem might be. 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 see this crash on both GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.org Windowing system distributor `Apple', version 10.3.1265 and the most recent emacs mac version by YAMAMOTO Mitsuharu. 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. I am unable to follow this suggestion (cannot compile emacs on my Mac), but perhaps it's useful to someone else. 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:~ $ ------------------------------------------------------------------------ --e89a8f234b55a246a304eca27d87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Emacs masters,

I have b= een experiencing repeated crashes on Emacs, and am wondering if the followi= ng reports could lead someone to figure out what the problem might be. =A0T= hese crashes occur after a few hours of normal use, almost always during re= ading mail with vm. =A0I am attaching an abbreviated backtrace when running= emacs under a debugger, and and the full one (8Mb) is available at https://www.dro= pbox.com/s/3hg8v9ct2omc8x9/emacs-bt.txt. =A0I am happy to try helping w= ith the debugging given specific instructions on commands to give lldb. =A0=

I see this crash on both=A0
GNU Emacs 24= .3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36)
=A0of 2013-03= -13 on bob.porkrind.org
W= indowing system distributor `Apple', version 10.3.1265
and the most recent emacs mac version by YAMAMOTO Mitsuharu.
=

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

> The ba= cktrace 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). =A0In = 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 bi= nary)
> by some formula in src/emacs.c:

> =A0 =A0817 =A0 = =A0 =A0long newlim;
> =A0 =A0818 =A0= =A0 =A0extern size_t re_max_failures;
> =A0 =A0819 =A0 =A0 =A0/* Approximate the amou= nt regex.c needs per unit of re_max_failures. =A0*/
> =A0 =A0820 =A0= =A0 =A0int ratio =3D 20 * sizeof (char *);
> =A0 =A0821 =A0 =A0 =A0/* Then add 33% to= cover the size of the smaller stacks that regex.c
> =A0 =A0822 su= ccessively allocates and discards, on its way to the maximum. =A0*/
> =A0 =A0823 =A0 = =A0 =A0ratio +=3D ratio / 3;
> =A0 =A0824 =A0= =A0 =A0/* Add in some extra to cover
> =A0 =A0825 what we're likely to use for = other reasons. =A0*/
> =A0 =A0826 =A0= =A0 =A0newlim =3D re_max_failures * ratio + 200000;

> Probably you can tweak the ratio value above and see if it mitigate= s
> the problem.

I am unable to follow this sugge= stion (cannot compile emacs on my Mac), but perhaps it's useful to some= one else.

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)
=A0of 2013-11-08 on Yukikaz= e.local
Windowing system distributor `Apple Inc.', version 10.9.0
Configured using:
=A0`configure '--with-mac' '--ena= ble-mac-app=3D/Users/xin/Documents/emacs-mac-port/build' '--prefix= =3D/Users/xin/Documents/emacs-mac-port/build''

Important settings:
=A0 locale-coding-system:= utf-8-unix
=A0 default enable-multibyte-characters: t
=
Major mode: Dired by name

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

Recent input:

Recent messages:
Loading .session...done
For informatio= n 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 f= iles
Deleting...done
Deleting...done
Making c= ompletion list...

Load-path shadows:
None found.

Features:
(shadow vm-reply v= m-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 w3= m-util mairix vm-rfaddons vm-page vm-minibuf emacsbug dired-aux info view c= al-china lunar solar cal-dst cal-bahai cal-islam cal-julian cal-hebrew holi= days hol-loaddefs mule-util cal-move goto-addr thingatpt cal-x em-unix em-t= erm term disp-table ehelp electric em-script em-prompt em-ls em-hist em-pre= d em-glob em-dirs em-cmpl em-basic em-banner em-alias esh-var esh-io esh-cm= d esh-opt esh-ext esh-proc esh-arg eldoc esh-groups eshell esh-module esh-m= ode esh-util srecode/srt-mode semantic/analyze semantic/sort semantic/scope= semantic/analyze/fcn semantic/format srecode/template srecode/srt-wy seman= tic/wisent semantic/wisent/wisent semantic/ctxt srecode/ctxt semantic/tag-l= s semantic/find srecode/compile srecode/dictionary srecode/table srecode/ma= p srecode semanticdb-matlab semantic/db semantic/util-modes semantic/util s= emantic semantic/tag semantic/lex semantic/fw mode-local cedet eieio-base e= ieio-opt help-mode speedbar sb-image ezimage dframe find-func cedet-matlab = matlab derived tempo matlab-load osx-osascript message-x server url url-pro= xy url-privacy url-expand url-methods url-history url-cookie url-domsuf url= -util mailcap telnet dired-efap bbdb-vcard-export bbdb-print sendmail flysp= ell message mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rf= c2047 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-a= utoloads bbdb timezone ffap url-parse url-vars auto-capitalize dired-x cl-m= acs gv rect-mark preview-latex tex-site auto-loads delsel appt cus-edit wid= -edit dictionary link connection icalendar diary-lib diary-loaddefs cal-men= u calendar cal-loaddefs rect ediff-merg ediff-diff ediff-wind ediff-help ed= iff-util ediff-mult ediff-init ediff dired ispell easymenu ibuffer edmacro = kmacro vm-autoloads vm-vars vm-version vm session uniquify warnings time im= age-file cus-start cus-load password cl tramp tramp-compat auth-source eiei= o byte-opt bytecomp byte-compile cconv gnus-util mm-util mail-prsvr passwor= d-cache tramp-loaddefs shell pcomplete comint ansi-color ring format-spec a= dvice 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 tim= er select scroll-bar mouse jit-lock font-lock syntax facemenu font-core fra= me 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 mini= buffer loaddefs button faces cus-face macroexp files text-properties overla= y 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 =A01 15:52:10 on ttys000
udp003015uds:~ $ lldb /A= pplications/Emacs.app/Contents/MacOS/Emacs
Current executable set= to '/Applications/Emacs.app/Contents/MacOS/Emacs' (x86_64).
(lldb) run
Process 5425 launched: '/Applications/Emacs.a= pp/Contents/MacOS/Emacs' (x86_64)
Process 5425 stopped and re= started: thread 1 received signal: SIGCHLD
Process 5425 stopped a= nd restarted: thread 1 received signal: SIGCHLD
Process 5425 stopped and restarted: thread 1 received signal: SIGCHLD<= /div>
Process 5425 stopped and restarted: thread 1 received signal: SIG= CHLD
Process 5425 stopped and restarted: thread 1 received signal= : SIGCHLD
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM<= /div>
...
Process 5425 stopped and restarted: thread 1 receiv= ed signal: SIGCHLD
Process 5425 stopped and restarted: thread 1 r= eceived signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM<= /div>
2013-12-01 15:56:54.773 Emacs[5425:d0b] -_continuousScroll is dep= recated for NSScrollWheel. Please use -hasPreciseScrollingDeltas.
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM<= /div>
Process 5425 stopped and restarted: thread 1 received signal: SIG= ALRM
Process 5425 stopped and restarted: thread 1 received signal= : SIGALRM
...
Process 5425 stopped and restarted: thread 1 received si= gnal: SIGALRM
Process 5425 stopped and restarted: thread 1 receiv= ed signal: SIGALRM
Process 5425 stopped and restarted: thread 1 r= eceived signal: SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM<= /div>
Process 5425 stopped and restarted: thread 1 received signal: SIG= CHLD
Process 5425 stopped and restarted: thread 1 received signal= : SIGALRM
Process 5425 stopped and restarted: thread 1 received signal: SIGALRM<= /div>
Process 5425 stopped and restarted: thread 1 received signal: SIG= ALRM
Process 5425 stopped
* thread #1: tid =3D 0x484e3,= 0x00000001000f61d1 Emacs`mark_object + 1073, queue =3D 'com.apple.main= -thread, stop reason =3D EXC_BAD_ACCESS (code=3D2, address=3D0x7fff5f3aeff8= )
=A0 =A0 frame #0: 0x00000001000f61d1 Emacs`mark_object + 1073
Emacs`mark_object + 1073:
-> 0x1000f61d1: =A0callq =A00x1000= f5da0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; mark_object
=A0 =A00x1000f61d= 6: =A0movq =A0 32(%r14), %rdi
=A0 =A00x1000f61da: =A0callq =A00x1000f5da0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ; mark_object
=A0 =A00x1000f61df: =A0movl =A0 (%r14), %eax
(lldb) bt
* thread #1: tid =3D 0x484e3, 0x00000001000f61d= 1 Emacs`mark_object + 1073, queue =3D 'com.apple.main-thread, stop reas= on =3D EXC_BAD_ACCESS (code=3D2, address=3D0x7fff5f3aeff8)
=A0 =A0 frame #0: 0x00000001000f61d1 Emacs`mark_object + 1073
=A0 =A0 frame #1: 0x00000001000f61a8 Emacs`mark_object + 1032
= =A0 =A0 frame #2: 0x00000001000f61a8 Emacs`mark_object + 1032
=A0= =A0 frame #3: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #4: 0x00000001000f62ab Emacs`mark_object + 1291
=A0 =A0 frame #5: 0x00000001000f61a8 Emacs`mark_object + 1032
= =A0 =A0 frame #6: 0x00000001000f61a8 Emacs`mark_object + 1032
=A0= =A0 frame #7: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #8: 0x00000001000f62ab Emacs`mark_object + 1291
=A0 =A0 frame #9: 0x00000001000f61a8 Emacs`mark_object + 1032
= =A0 =A0 frame #10: 0x00000001000f61a8 Emacs`mark_object + 1032
= =A0 =A0 frame #11: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #12: 0x00000001000f62ab Emacs`mark_object + 1291
...
=A0 =A0 frame #136042: 0x00000001000f61df Emacs`mark_objec= t + 1087
=A0 =A0 frame #136043: 0x00000001000f6443 Emacs`mark_obj= ect + 1699
=A0 =A0 frame #136044: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136045: 0x00000001000f61df Emacs`mark_object + 1087
=A0 =A0 frame #136046: 0x00000001000f6443 Emacs`mark_object + 1699=
=A0 =A0 frame #136047: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136048: 0x00000001000f61df Emacs`mark_object + 1087
<= div>=A0 =A0 frame #136049: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136050: 0x00000001000f5e20 Emacs`mark_object + 128
=A0 =A0 frame #136051: 0x00000001000f61d6 Emacs`mark_object + 1078
=A0 =A0 frame #136052: 0x00000001000f61a8 Emacs`mark_object + 1032
=A0 =A0 frame #136053: 0x00000001000f61d6 Emacs`mark_object + 1078=
=A0 =A0 frame #136054: 0x00000001000f61a8 Emacs`mark_object + 1032
=A0 =A0 frame #136055: 0x00000001000f61d6 Emacs`mark_object + 1078
<= div>=A0 =A0 frame #136056: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136057: 0x00000001000f61df Emacs`mark_object + 1087
=A0 =A0 frame #136058: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136059: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136060: 0x00000001000f61df Emacs`mark_object + 1087=
=A0 =A0 frame #136061: 0x00000001000f61a8 Emacs`mark_object + 1032
=A0 =A0 frame #136062: 0x00000001000f61d6 Emacs`mark_object + 1078
<= div>=A0 =A0 frame #136063: 0x00000001000f61df Emacs`mark_object + 1087
=A0 =A0 frame #136064: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136065: 0x00000001000f61df Emacs`mark_object + 1087
=A0 =A0 frame #136066: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136067: 0x00000001000f61df Emacs`mark_object + 1087=
=A0 =A0 frame #136068: 0x00000001000f61a8 Emacs`mark_object + 1032
=A0 =A0 frame #136069: 0x00000001000f61d6 Emacs`mark_object + 1078
<= div>=A0 =A0 frame #136070: 0x00000001000f61a8 Emacs`mark_object + 1032
=A0 =A0 frame #136071: 0x00000001000f61d6 Emacs`mark_object + 1078
=A0 =A0 frame #136072: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136073: 0x00000001000f61df Emacs`mark_object + 1087
=A0 =A0 frame #136074: 0x00000001000f6443 Emacs`mark_object + 1699=
=A0 =A0 frame #136075: 0x00000001000f61df Emacs`mark_object + 1087
=A0 =A0 frame #136076: 0x00000001000f6443 Emacs`mark_object + 1699
<= div>=A0 =A0 frame #136077: 0x00000001000f61df Emacs`mark_object + 1087
=A0 =A0 frame #136078: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136079: 0x00000001000f61df Emacs`mark_object + 1087
=A0 =A0 frame #136080: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136081: 0x00000001000f61df Emacs`mark_object + 1087=
=A0 =A0 frame #136082: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136083: 0x00000001000f61df Emacs`mark_object + 1087
<= div>=A0 =A0 frame #136084: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136085: 0x00000001000f61df Emacs`mark_object + 1087
=A0 =A0 frame #136086: 0x00000001000f6443 Emacs`mark_object + 1699
=A0 =A0 frame #136087: 0x00000001000f65a9 Emacs`mark_buffer + 105
=A0 =A0 frame #136088: 0x00000001000faffd Emacs`Fgarbage_collect + = 637
=A0 =A0 frame #136089: 0x000000010014ad63 Emacs`exec_byte_code + 1027<= /div>
=A0 =A0 frame #136090: 0x00000001001169b7 Emacs`funcall_lambda + = 871
=A0 =A0 frame #136091: 0x0000000100113968 Emacs`Ffuncall + 11= 60
=A0 =A0 frame #136092: 0x000000010014b108 Emacs`exec_byte_code + 1960<= /div>
=A0 =A0 frame #136093: 0x00000001001169b7 Emacs`funcall_lambda + = 871
=A0 =A0 frame #136094: 0x0000000100113968 Emacs`Ffuncall + 11= 60
=A0 =A0 frame #136095: 0x000000010014b108 Emacs`exec_byte_code + 1960<= /div>
=A0 =A0 frame #136096: 0x00000001001169b7 Emacs`funcall_lambda + = 871
=A0 =A0 frame #136097: 0x0000000100113968 Emacs`Ffuncall + 11= 60
=A0 =A0 frame #136098: 0x0000000100116b5e Emacs`call1 + 30
= =A0 =A0 frame #136099: 0x0000000100131c4b Emacs`Fmapatoms + 203
= =A0 =A0 frame #136100: 0x0000000100113990 Emacs`Ffuncall + 1200
= =A0 =A0 frame #136101: 0x000000010014b108 Emacs`exec_byte_code + 1960
=A0 =A0 frame #136102: 0x00000001001169b7 Emacs`funcall_lambda + 871
=A0 =A0 frame #136103: 0x0000000100113968 Emacs`Ffuncall + 1160
=A0 =A0 frame #136104: 0x000000010014b108 Emacs`exec_byte_code + 19= 60
=A0 =A0 frame #136105: 0x00000001001169b7 Emacs`funcall_lambda + 871
=A0 =A0 frame #136106: 0x0000000100113968 Emacs`Ffuncall + 1160
=A0 =A0 frame #136107: 0x000000010014b108 Emacs`exec_byte_code + 19= 60
=A0 =A0 frame #136108: 0x00000001001161d7 Emacs`eval_sub + 1463
<= div>=A0 =A0 frame #136109: 0x00000001001152f5 Emacs`internal_catch + 213
=A0 =A0 frame #136110: 0x000000010014bca4 Emacs`exec_byte_code + 49= 32
=A0 =A0 frame #136111: 0x00000001001169b7 Emacs`funcall_lambda + 871
=A0 =A0 frame #136112: 0x0000000100113968 Emacs`Ffuncall + 1160
=A0 =A0 frame #136113: 0x000000010014b108 Emacs`exec_byte_code + 19= 60
=A0 =A0 frame #136114: 0x00000001001169b7 Emacs`funcall_lambda + 871
=A0 =A0 frame #136115: 0x00000001001165b3 Emacs`apply_lambda + 291=
=A0 =A0 frame #136116: 0x00000001001162f7 Emacs`eval_sub + 1751<= /div>
=A0 =A0 frame #136117: 0x0000000100111509 Emacs`Fprogn + 41
=A0 = =A0 frame #136118: 0x000000010010709e Emacs`Fsave_excursion + 62
= =A0 =A0 frame #136119: 0x0000000100115f95 Emacs`eval_sub + 885
= =A0 =A0 frame #136120: 0x0000000100116969 Emacs`funcall_lambda + 793
=A0 =A0 frame #136121: 0x0000000100113968 Emacs`Ffuncall + 1160
<= div>=A0 =A0 frame #136122: 0x00000001001158f6 Emacs`apply1 + 38
= =A0 =A0 frame #136123: 0x000000010010f8b9 Emacs`Fcall_interactively + 1321<= /div>
=A0 =A0 frame #136124: 0x00000001001138a4 Emacs`Ffuncall + 964
= =A0 =A0 frame #136125: 0x0000000100116b36 Emacs`call3 + 38
=A0 = =A0 frame #136126: 0x00000001000aeb12 Emacs`command_loop_1 + 1554
=A0 =A0 frame #136127: 0x00000001001151f9 Emacs`internal_condition_case + = 297
=A0 =A0 frame #136128: 0x00000001000ae4dd Emacs`command_loop_2 + 77
=A0 =A0 frame #136129: 0x00000001001152f5 Emacs`internal_catch + 21= 3
=A0 =A0 frame #136130: 0x00000001000afee2 Emacs`recursive_edit_= 1 + 226
=A0 =A0 frame #136131: 0x00000001000a0b67 Emacs`Frecursive_edit + 231<= /div>
=A0 =A0 frame #136132: 0x000000010009d8b8 Emacs`main + 5208
=
=A0 =A0 frame #136133: 0x0000000100002554 Emacs`start + 52
(= lldb) exit
Quitting LLDB will kill one or more processes. Do you really want to p= roceed: [Y/n] y
udp003015uds:~ $
----------------------= --------------------------------------------------

--e89a8f234b55a246a304eca27d87-- From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 03 11:01:53 2013 Received: (at 16039) by debbugs.gnu.org; 3 Dec 2013 16:01:53 +0000 Received: from localhost ([127.0.0.1]:56580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnsQ4-00033L-JS for submit@debbugs.gnu.org; Tue, 03 Dec 2013 11:01:53 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:63253) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnsQ1-000337-PL for 16039@debbugs.gnu.org; Tue, 03 Dec 2013 11:01:50 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MX800700N58HW00@a-mtaout20.012.net.il> for 16039@debbugs.gnu.org; Tue, 03 Dec 2013 18:01:19 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MX8007V1N67GS10@a-mtaout20.012.net.il>; Tue, 03 Dec 2013 18:01:19 +0200 (IST) Date: Tue, 03 Dec 2013 18:01:21 +0200 From: Eli Zaretskii Subject: Re: bug#16039: repeated emacs crashes (in GC?) In-reply-to: X-012-Sender: halo1@inter.net.il To: emacs user Message-id: <83k3fl53fy.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16039 Cc: 16039@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 3 Dec 2013 16:55:43 +0200 > From: emacs user > > 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: What is the evidence that the stack is used up? Having 136 thousand frames during GC is not unheard of. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 03 19:43:08 2013 Received: (at 16039) by debbugs.gnu.org; 4 Dec 2013 00:43:08 +0000 Received: from localhost ([127.0.0.1]:57004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vo0YV-0001KA-OM for submit@debbugs.gnu.org; Tue, 03 Dec 2013 19:43:08 -0500 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:51594) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vo0YT-0001Jm-2q for 16039@debbugs.gnu.org; Tue, 03 Dec 2013 19:43:06 -0500 Received: from fermat.math.s.chiba-u.ac.jp (fermat [133.82.132.10]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 73A95C055D; Wed, 4 Dec 2013 09:43:00 +0900 (JST) Date: Wed, 04 Dec 2013 09:43:00 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Eli Zaretskii Subject: Re: bug#16039: repeated emacs crashes (in GC?) In-Reply-To: <83k3fl53fy.fsf@gnu.org> References: <83k3fl53fy.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 16039 Cc: 16039@debbugs.gnu.org, emacs user X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >>>>> On Tue, 03 Dec 2013 18:01:21 +0200, Eli Zaretskii said: >> 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: > What is the evidence that the stack is used up? The backtrace shows it crashed by accessing the address exceeding the stack boundary: * thread #1: tid = 0x484e3, 0x00000001000f61d1 Emacs`mark_object + 1073, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5f3aeff8) Below is extracted from the memory map (% vmmap -interleaved PID): STACK GUARD 00007fff5bc00000-00007fff5f3af000 [ 55.7M] ---/rwx SM=NUL stack guard for thread 0 Stack 00007fff5f3af000-00007fff5f400000 [ 324K] rw-/rwx SM=NUL thread 0 Stack 00007fff5f400000-00007fff5fbff000 [ 8188K] rw-/rwx SM=PRV thread 0 > Having 136 thousand frames during GC is not unheard of. (/ 8720000.0 (* 136 1000)) 64.11764705882354 If each frame consumes more than 64 bytes, then it will use up 8720000B stack space. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 03 20:48:23 2013 Received: (at 16039) by debbugs.gnu.org; 4 Dec 2013 01:48:23 +0000 Received: from localhost ([127.0.0.1]:57038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vo1Ze-0002xr-DG for submit@debbugs.gnu.org; Tue, 03 Dec 2013 20:48:23 -0500 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:51539) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vo1ZX-0002xZ-9Z for 16039@debbugs.gnu.org; Tue, 03 Dec 2013 20:48:17 -0500 Received: from fermat.math.s.chiba-u.ac.jp (fermat [133.82.132.10]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 9A10CC055D; Wed, 4 Dec 2013 10:48:11 +0900 (JST) Date: Wed, 04 Dec 2013 10:48:11 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Eli Zaretskii Subject: Re: bug#16039: repeated emacs crashes (in GC?) In-Reply-To: References: <83k3fl53fy.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 16039 Cc: 16039@debbugs.gnu.org, emacs user X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >>>>> On Wed, 04 Dec 2013 09:43:00 +0900, YAMAMOTO Mitsuharu said: >> Having 136 thousand frames during GC is not unheard of. > (/ 8720000.0 (* 136 1000)) > 64.11764705882354 > If each frame consumes more than 64 bytes, then it will use up > 8720000B stack space. FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the -O2 option seems to consume 64 bytes for each mark_object frame: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) _mark_object: 00000000000008a0 pushq %rbp 00000000000008a1 movq %rsp, %rbp 00000000000008a4 movq %rbx, 0xffffffffffffffd8(%rbp) 00000000000008a8 movq %r12, 0xffffffffffffffe0(%rbp) 00000000000008ac movq %r13, 0xffffffffffffffe8(%rbp) 00000000000008b0 movq %r14, 0xfffffffffffffff0(%rbp) 00000000000008b4 movq %r15, 0xfffffffffffffff8(%rbp) 00000000000008b8 subq $0x40, %rsp And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) _mark_object: 0000000000005c70 pushq %rbp 0000000000005c71 movq %rsp, %rbp 0000000000005c74 pushq %r15 0000000000005c76 pushq %r14 0000000000005c78 pushq %r13 0000000000005c7a pushq %r12 0000000000005c7c pushq %rbx 0000000000005c7d subq $0x18, %rsp YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 03 22:49:48 2013 Received: (at 16039) by debbugs.gnu.org; 4 Dec 2013 03:49:48 +0000 Received: from localhost ([127.0.0.1]:57111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vo3TA-00060c-4U for submit@debbugs.gnu.org; Tue, 03 Dec 2013 22:49:48 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:42127) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vo3T6-00060P-MT for 16039@debbugs.gnu.org; Tue, 03 Dec 2013 22:49:46 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MX900800JSP0E00@a-mtaout22.012.net.il> for 16039@debbugs.gnu.org; Wed, 04 Dec 2013 05:49:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MX9007K2JYUTT60@a-mtaout22.012.net.il>; Wed, 04 Dec 2013 05:49:42 +0200 (IST) Date: Wed, 04 Dec 2013 05:49:46 +0200 From: Eli Zaretskii Subject: Re: bug#16039: repeated emacs crashes (in GC?) In-reply-to: X-012-Sender: halo1@inter.net.il To: YAMAMOTO Mitsuharu Message-id: <838uw146n9.fsf@gnu.org> References: <83k3fl53fy.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16039 Cc: 16039@debbugs.gnu.org, user.emacs@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 04 Dec 2013 09:43:00 +0900 > From: YAMAMOTO Mitsuharu > Cc: emacs user , > 16039@debbugs.gnu.org > > >>>>> On Tue, 03 Dec 2013 18:01:21 +0200, Eli Zaretskii said: > > >> 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: > > > What is the evidence that the stack is used up? > > The backtrace shows it crashed by accessing the address exceeding the > stack boundary: > > * thread #1: tid = 0x484e3, 0x00000001000f61d1 Emacs`mark_object + 1073, > queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=2, > address=0x7fff5f3aeff8) > > Below is extracted from the memory map (% vmmap -interleaved PID): > > STACK GUARD 00007fff5bc00000-00007fff5f3af000 [ 55.7M] ---/rwx SM=NUL stack guard for thread 0 > Stack 00007fff5f3af000-00007fff5f400000 [ 324K] rw-/rwx SM=NUL thread 0 > Stack 00007fff5f400000-00007fff5fbff000 [ 8188K] rw-/rwx SM=PRV thread 0 > > > Having 136 thousand frames during GC is not unheard of. > > (/ 8720000.0 (* 136 1000)) > 64.11764705882354 > > If each frame consumes more than 64 bytes, then it will use up > 8720000B stack space. Thanks. I'd suggest to enlarge the stack (e.g., double it), and try again. If the stack is still overflowed, then there's probably some GC-related problem. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 04 01:33:18 2013 Received: (at 16039) by debbugs.gnu.org; 4 Dec 2013 06:33:18 +0000 Received: from localhost ([127.0.0.1]:57191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vo61N-0001ey-3q for submit@debbugs.gnu.org; Wed, 04 Dec 2013 01:33:17 -0500 Received: from mail-wi0-f173.google.com ([209.85.212.173]:37587) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vo61K-0001ep-20 for 16039@debbugs.gnu.org; Wed, 04 Dec 2013 01:33:14 -0500 Received: by mail-wi0-f173.google.com with SMTP id hn9so3340651wib.6 for <16039@debbugs.gnu.org>; Tue, 03 Dec 2013 22:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UbmGcMWfvbzfaXikbgdq4sJGw8rxPcVp7NguYWVlNlM=; b=apdxDyJ7lphKwGmosxgltzwGD/3+DMgKPAMxEUNZIwb4KVBnyPSd8X875zisbdOzHN 78Jvc4KY/HsSqduaCqSVA0ZHa185apd/0CCdwFhgriMVxh878uJ8JBYnhJQQTlHn1lLn /GLskR8PqSPsh2RG2/l25SHrozko0hIKcTy72v/hVySj+LbXOUcAurjjJZDw3ms4EiSP BjAcC70Ajj87ITRqs3b5/8GoOBZZ/TGI7yTlbJqcqHytNyCWtVJgOrmylSlGSxCugPJZ dMzRwPxsgT9SE+QpjubRV5J3YPffSy83UjSZ8SHrOpj3WrX3n2MeIYX2fzSAQNo/3RsZ S3WQ== MIME-Version: 1.0 X-Received: by 10.194.173.163 with SMTP id bl3mr63058881wjc.10.1386138793070; Tue, 03 Dec 2013 22:33:13 -0800 (PST) Received: by 10.216.47.129 with HTTP; Tue, 3 Dec 2013 22:33:13 -0800 (PST) In-Reply-To: <838uw146n9.fsf@gnu.org> References: <83k3fl53fy.fsf@gnu.org> <838uw146n9.fsf@gnu.org> Date: Wed, 4 Dec 2013 08:33:13 +0200 Message-ID: Subject: Re: bug#16039: repeated emacs crashes (in GC?) From: emacs user To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e013c62205ed68104ecaf9621 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16039 Cc: 16039@debbugs.gnu.org, YAMAMOTO Mitsuharu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e013c62205ed68104ecaf9621 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 4, 2013 at 5:49 AM, Eli Zaretskii wrote: > > > Thanks. I'd suggest to enlarge the stack (e.g., double it), and try > again. If the stack is still overflowed, then there's probably some > GC-related problem. > thanks to both of you for this. I am very happy to test such a modified version. am unfortunately not able to make this change and recompile. best, E --089e013c62205ed68104ecaf9621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Dec 4, 2013 at 5:49 AM, Eli Zaretskii <= ;eliz@gnu.org> wrote:

Thanks. =A0I'd suggest to enlarge the stack (e.g., double it), and try<= br> again. =A0If the stack is still overflowed, then there's probably some<= br> GC-related problem.

thanks to both of y= ou for this. =A0I am very happy to test such a modified version. =A0am unfo= rtunately not able to make this change and recompile. =A0best, E
= =A0

--089e013c62205ed68104ecaf9621-- From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 04 19:35:33 2013 Received: (at 16039) by debbugs.gnu.org; 5 Dec 2013 00:35:33 +0000 Received: from localhost ([127.0.0.1]:58587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoMui-00070W-HD for submit@debbugs.gnu.org; Wed, 04 Dec 2013 19:35:32 -0500 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:50711) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoMub-000705-4j for 16039@debbugs.gnu.org; Wed, 04 Dec 2013 19:35:30 -0500 Received: from fermat.math.s.chiba-u.ac.jp (fermat [133.82.132.10]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 5FD86C055D; Thu, 5 Dec 2013 09:35:21 +0900 (JST) Date: Thu, 05 Dec 2013 09:35:21 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Eli Zaretskii Subject: Re: bug#16039: repeated emacs crashes (in GC?) In-Reply-To: References: <83k3fl53fy.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 16039 Cc: 16039@debbugs.gnu.org, emacs user X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >>>>> On Wed, 04 Dec 2013 10:48:11 +0900, YAMAMOTO Mitsuharu said: >>> Having 136 thousand frames during GC is not unheard of. >> (/ 8720000.0 (* 136 1000)) >> 64.11764705882354 >> If each frame consumes more than 64 bytes, then it will use up >> 8720000B stack space. > FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the > -O2 option seems to consume 64 bytes for each mark_object frame: > i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) > _mark_object: > 00000000000008a0 pushq %rbp > 00000000000008a1 movq %rsp, %rbp > 00000000000008a4 movq %rbx, 0xffffffffffffffd8(%rbp) > 00000000000008a8 movq %r12, 0xffffffffffffffe0(%rbp) > 00000000000008ac movq %r13, 0xffffffffffffffe8(%rbp) > 00000000000008b0 movq %r14, 0xfffffffffffffff0(%rbp) > 00000000000008b4 movq %r15, 0xfffffffffffffff8(%rbp) > 00000000000008b8 subq $0x40, %rsp > And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes: > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > _mark_object: > 0000000000005c70 pushq %rbp > 0000000000005c71 movq %rsp, %rbp > 0000000000005c74 pushq %r15 > 0000000000005c76 pushq %r14 > 0000000000005c78 pushq %r13 > 0000000000005c7a pushq %r12 > 0000000000005c7c pushq %rbx > 0000000000005c7d subq $0x18, %rsp I forgot to count the pushq instructions. The correct value would be 72 bytes for each mark_object frame in both cases. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 01:54:19 2013 Received: (at 16039) by debbugs.gnu.org; 5 Dec 2013 06:54:19 +0000 Received: from localhost ([127.0.0.1]:58846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoSpF-0001cK-ST for submit@debbugs.gnu.org; Thu, 05 Dec 2013 01:54:18 -0500 Received: from mail-wg0-f52.google.com ([74.125.82.52]:53664) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoSpC-0001cA-0q for 16039@debbugs.gnu.org; Thu, 05 Dec 2013 01:54:15 -0500 Received: by mail-wg0-f52.google.com with SMTP id x13so16064683wgg.31 for <16039@debbugs.gnu.org>; Wed, 04 Dec 2013 22:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d/tHJqbz13hyUKRkL+d6KpHPnOFUauuPe05e4JkGhwY=; b=r/wHbo9SK44uBx75OVWbuXdPSzxpU/9HKISqj4CipVBbR1DMQi2TwPbSG6yZ6zQ6OA D6w7eWiH18RTH5NxvokL4zfFX9IUydqak9ZK/rVJkSYA/PMyIvrT6QCNZPouu9loX9YO TfMhMgle+P/ENhPJQ6GL2mfjM2R230/uIm48aT8QAiZPohJtMIjv8zRXjD7zxreq9JpF m5hOamG6EzsHvLlhcFTKqtWBowHUPQmb2OnFnGQh0NP8eWCc/4rMCYa5zbExLVchHXZs U+BB5LRz5y3t8aoipKDrLzRKICQsKEbkv4OwzQSeh9kRkLLqDEjkVWwS0/c/PnKLFv9P fXnQ== MIME-Version: 1.0 X-Received: by 10.194.173.163 with SMTP id bl3mr68167395wjc.10.1386226453061; Wed, 04 Dec 2013 22:54:13 -0800 (PST) Received: by 10.216.47.129 with HTTP; Wed, 4 Dec 2013 22:54:13 -0800 (PST) In-Reply-To: References: <83k3fl53fy.fsf@gnu.org> Date: Thu, 5 Dec 2013 08:54:13 +0200 Message-ID: Subject: Re: bug#16039: repeated emacs crashes (in GC?) From: emacs user To: YAMAMOTO Mitsuharu Content-Type: multipart/alternative; boundary=089e013c62205025aa04ecc3ffd0 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16039 Cc: Eli Zaretskii , 16039@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e013c62205025aa04ecc3ffd0 Content-Type: text/plain; charset=ISO-8859-1 I managed to compile your mac port and inserted: newlim = (re_max_failures * ratio + 200000)*2; will let you know in a few days if I still see crashes. On Thu, Dec 5, 2013 at 2:35 AM, YAMAMOTO Mitsuharu < mituharu@math.s.chiba-u.ac.jp> wrote: > >>>>> On Wed, 04 Dec 2013 10:48:11 +0900, YAMAMOTO Mitsuharu < > mituharu@math.s.chiba-u.ac.jp> said: > > >>> Having 136 thousand frames during GC is not unheard of. > > >> (/ 8720000.0 (* 136 1000)) > >> 64.11764705882354 > > >> If each frame consumes more than 64 bytes, then it will use up > >> 8720000B stack space. > > > FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the > > -O2 option seems to consume 64 bytes for each mark_object frame: > > > i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot > 3) > > > _mark_object: > > 00000000000008a0 pushq %rbp > > 00000000000008a1 movq %rsp, %rbp > > 00000000000008a4 movq %rbx, 0xffffffffffffffd8(%rbp) > > 00000000000008a8 movq %r12, 0xffffffffffffffe0(%rbp) > > 00000000000008ac movq %r13, 0xffffffffffffffe8(%rbp) > > 00000000000008b0 movq %r14, 0xfffffffffffffff0(%rbp) > > 00000000000008b4 movq %r15, 0xfffffffffffffff8(%rbp) > > 00000000000008b8 subq $0x40, %rsp > > > And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes: > > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > > _mark_object: > > 0000000000005c70 pushq %rbp > > 0000000000005c71 movq %rsp, %rbp > > 0000000000005c74 pushq %r15 > > 0000000000005c76 pushq %r14 > > 0000000000005c78 pushq %r13 > > 0000000000005c7a pushq %r12 > > 0000000000005c7c pushq %rbx > > 0000000000005c7d subq $0x18, %rsp > > I forgot to count the pushq instructions. The correct value would be > 72 bytes for each mark_object frame in both cases. > > YAMAMOTO Mitsuharu > mituharu@math.s.chiba-u.ac.jp > --089e013c62205025aa04ecc3ffd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I managed to compile your mac port and inserted:
=
=A0 =A0 =A0 newlim =3D (re_max_failures * ratio + 200000)*2;=

will let you know in a few days if I still = see crashes.


On Thu,= Dec 5, 2013 at 2:35 AM, YAMAMOTO Mitsuharu <mituharu@math.s= .chiba-u.ac.jp> wrote:
>>>>> On Wed, 04 Dec 2013 10:= 48:11 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> Having 136 thousand frames during GC is not unheard of.

>> (/ 8720000.0 (* 136 1000))
>> 64.11764705882354

>> If each frame consumes more than 64 bytes, then it will use up
>> 8720000B stack space.

> FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the > -O2 option seems to consume 64 bytes for each mark_object frame:

> =A0 i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) = (dot 3)

> =A0 _mark_object:
> =A0 00000000000008a0 =A0 =A0pushq =A0 %rbp
> =A0 00000000000008a1 =A0 =A0movq =A0 =A0%rsp, %rbp
> =A0 00000000000008a4 =A0 =A0movq =A0 =A0%rbx, 0xffffffffffffffd8(%rbp)=
> =A0 00000000000008a8 =A0 =A0movq =A0 =A0%r12, 0xffffffffffffffe0(%rbp)=
> =A0 00000000000008ac =A0 =A0movq =A0 =A0%r13, 0xffffffffffffffe8(%rbp)=
> =A0 00000000000008b0 =A0 =A0movq =A0 =A0%r14, 0xfffffffffffffff0(%rbp)=
> =A0 00000000000008b4 =A0 =A0movq =A0 =A0%r15, 0xfffffffffffffff8(%rbp)=
> =A0 00000000000008b8 =A0 =A0subq =A0 =A0$0x40, %rsp

> And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes:

> =A0 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)

> =A0 _mark_object:
> =A0 0000000000005c70 =A0 =A0pushq =A0 %rbp
> =A0 0000000000005c71 =A0 =A0movq =A0 =A0%rsp, %rbp
> =A0 0000000000005c74 =A0 =A0pushq =A0 %r15
> =A0 0000000000005c76 =A0 =A0pushq =A0 %r14
> =A0 0000000000005c78 =A0 =A0pushq =A0 %r13
> =A0 0000000000005c7a =A0 =A0pushq =A0 %r12
> =A0 0000000000005c7c =A0 =A0pushq =A0 %rbx
> =A0 0000000000005c7d =A0 =A0subq =A0 =A0$0x18, %rsp

I forgot to count the pushq instructions. =A0The correct value would be
72 bytes for each mark_object frame in both cases.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= YAMAMOTO Mitsuharu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mituharu@math.s.chiba-u.ac.jp

--089e013c62205025aa04ecc3ffd0-- From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 15:29:54 2013 Received: (at 16039) by debbugs.gnu.org; 7 Dec 2013 20:29:55 +0000 Received: from localhost ([127.0.0.1]:36935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpOVe-0002OU-5E for submit@debbugs.gnu.org; Sat, 07 Dec 2013 15:29:54 -0500 Received: from mail-we0-f174.google.com ([74.125.82.174]:63830) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpOVZ-0002OJ-Es for 16039@debbugs.gnu.org; Sat, 07 Dec 2013 15:29:51 -0500 Received: by mail-we0-f174.google.com with SMTP id q58so1961611wes.5 for <16039@debbugs.gnu.org>; Sat, 07 Dec 2013 12:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HItmoGsASKQWyLyV7VmcGFNabMxQsQvy9lKnGdK1q24=; b=zbZkC3CdGtkSjEcXh5LJEMwI/a2fpnQOrQcjpORKXFxjAp0gdcubLdlWhR/S58Ashv Yn9JTrEWfQlAsrpRkc+44ZYjtJ8lvX2n5XXLNJCQbe70tg/2/9VtW7IcScSXucJ7GxIT pQXUh912D79uRaGcwpaVMrVVJ85cnE0Qfnqq1nZUHJhaIS+JKkLmgeBigTg6eMeL40XO N4FSE+jUPlsGqIFdo3ktUDRaG7YufKw6xjCEyQHE4Dv16CRN5/PQlaVf4KUiHZE17/C/ UoACGLqMYYG2uUb6qPlHSWYTuXbz5AotYnMSx0UqyYZwUx7xz7r1MC6n3Dxg2IVd2O26 hHcw== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr8983431wjc.9.1386448188540; Sat, 07 Dec 2013 12:29:48 -0800 (PST) Received: by 10.216.47.129 with HTTP; Sat, 7 Dec 2013 12:29:48 -0800 (PST) Date: Sat, 7 Dec 2013 22:29:48 +0200 Message-ID: Subject: Re: bug#16039: repeated emacs crashes (in GC?) From: emacs user To: YAMAMOTO Mitsuharu Content-Type: multipart/alternative; boundary=047d7b873a10c70a3804ecf79fb7 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16039 Cc: Eli Zaretskii , 16039@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b873a10c70a3804ecf79fb7 Content-Type: text/plain; charset=ISO-8859-1 so after running the same emacs session for 72 hours, during which I used vm many times and emacs used a total of 1.5 CPU hours, I think it is safe to say that this problem that caused frequent crashes is fixed by the increase in newlim as specified below. I hope something like this can be implemented in the emacs development version. Thanks for your help, best, E On Thu, Dec 5, 2013 at 8:54 AM, emacs user wrote: > I managed to compile your mac port and inserted: > > newlim = (re_max_failures * ratio + 200000)*2; > > will let you know in a few days if I still see crashes. > > > On Thu, Dec 5, 2013 at 2:35 AM, YAMAMOTO Mitsuharu < > mituharu@math.s.chiba-u.ac.jp> wrote: > >> >>>>> On Wed, 04 Dec 2013 10:48:11 +0900, YAMAMOTO Mitsuharu < >> mituharu@math.s.chiba-u.ac.jp> said: >> >> >>> Having 136 thousand frames during GC is not unheard of. >> >> >> (/ 8720000.0 (* 136 1000)) >> >> 64.11764705882354 >> >> >> If each frame consumes more than 64 bytes, then it will use up >> >> 8720000B stack space. >> >> > FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the >> > -O2 option seems to consume 64 bytes for each mark_object frame: >> >> > i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) >> (dot 3) >> >> > _mark_object: >> > 00000000000008a0 pushq %rbp >> > 00000000000008a1 movq %rsp, %rbp >> > 00000000000008a4 movq %rbx, 0xffffffffffffffd8(%rbp) >> > 00000000000008a8 movq %r12, 0xffffffffffffffe0(%rbp) >> > 00000000000008ac movq %r13, 0xffffffffffffffe8(%rbp) >> > 00000000000008b0 movq %r14, 0xfffffffffffffff0(%rbp) >> > 00000000000008b4 movq %r15, 0xfffffffffffffff8(%rbp) >> > 00000000000008b8 subq $0x40, %rsp >> >> > And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes: >> >> > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> > _mark_object: >> > 0000000000005c70 pushq %rbp >> > 0000000000005c71 movq %rsp, %rbp >> > 0000000000005c74 pushq %r15 >> > 0000000000005c76 pushq %r14 >> > 0000000000005c78 pushq %r13 >> > 0000000000005c7a pushq %r12 >> > 0000000000005c7c pushq %rbx >> > 0000000000005c7d subq $0x18, %rsp >> >> I forgot to count the pushq instructions. The correct value would be >> 72 bytes for each mark_object frame in both cases. >> >> YAMAMOTO Mitsuharu >> mituharu@math.s.chiba-u.ac.jp >> > > --047d7b873a10c70a3804ecf79fb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
so after running the same emacs session for 72 hours, duri= ng which I used vm many times and emacs used a total of 1.5 CPU hours, I th= ink it is safe to say that this problem that caused frequent crashes is fix= ed by the increase in=A0newlim=A0as specified below. I hope something like = this can be implemented in the emacs development version. =A0 Thanks for yo= ur help,=A0best, E


On Thu, Dec 5= , 2013 at 8:54 AM, emacs user <user.emacs@gmail.com> wrot= e:
I managed to compile your mac port and in= serted:

=A0 =A0 =A0 newlim =3D (re_max_failures * ratio + 20000= 0)*2;

will let you know in a few days if I s= till see crashes.


On Thu,= Dec 5, 2013 at 2:35 AM, YAMAMOTO Mitsuharu <mituharu@math.s= .chiba-u.ac.jp> wrote:
>>>>> On Wed, 04 Dec 2013 10:48:11 +0900, Y= AMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> Having 136 thousand frames during GC is not unheard of.

>> (/ 8720000.0 (* 136 1000))
>> 64.11764705882354

>> If each frame consumes more than 64 bytes, then it will use up
>> 8720000B stack space.

> FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the > -O2 option seems to consume 64 bytes for each mark_object frame:

> =A0 i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) = (dot 3)

> =A0 _mark_object:
> =A0 00000000000008a0 =A0 =A0pushq =A0 %rbp
> =A0 00000000000008a1 =A0 =A0movq =A0 =A0%rsp, %rbp
> =A0 00000000000008a4 =A0 =A0movq =A0 =A0%rbx, 0xffffffffffffffd8(%rbp)=
> =A0 00000000000008a8 =A0 =A0movq =A0 =A0%r12, 0xffffffffffffffe0(%rbp)=
> =A0 00000000000008ac =A0 =A0movq =A0 =A0%r13, 0xffffffffffffffe8(%rbp)=
> =A0 00000000000008b0 =A0 =A0movq =A0 =A0%r14, 0xfffffffffffffff0(%rbp)=
> =A0 00000000000008b4 =A0 =A0movq =A0 =A0%r15, 0xfffffffffffffff8(%rbp)=
> =A0 00000000000008b8 =A0 =A0subq =A0 =A0$0x40, %rsp

> And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes:

> =A0 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)

> =A0 _mark_object:
> =A0 0000000000005c70 =A0 =A0pushq =A0 %rbp
> =A0 0000000000005c71 =A0 =A0movq =A0 =A0%rsp, %rbp
> =A0 0000000000005c74 =A0 =A0pushq =A0 %r15
> =A0 0000000000005c76 =A0 =A0pushq =A0 %r14
> =A0 0000000000005c78 =A0 =A0pushq =A0 %r13
> =A0 0000000000005c7a =A0 =A0pushq =A0 %r12
> =A0 0000000000005c7c =A0 =A0pushq =A0 %rbx
> =A0 0000000000005c7d =A0 =A0subq =A0 =A0$0x18, %rsp

I forgot to count the pushq instructions. =A0The correct value would be
72 bytes for each mark_object frame in both cases.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= YAMAMOTO Mitsuharu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mituharu@math.s.chi= ba-u.ac.jp


--047d7b873a10c70a3804ecf79fb7-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 15 12:17:24 2013 Received: (at 16039) by debbugs.gnu.org; 15 Dec 2013 17:17:25 +0000 Received: from localhost ([127.0.0.1]:51908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VsFJj-0008V9-Ug for submit@debbugs.gnu.org; Sun, 15 Dec 2013 12:17:24 -0500 Received: from mail-wi0-f181.google.com ([209.85.212.181]:43626) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VsFJh-0008V0-3K for 16039@debbugs.gnu.org; Sun, 15 Dec 2013 12:17:22 -0500 Received: by mail-wi0-f181.google.com with SMTP id hq4so1193218wib.8 for <16039@debbugs.gnu.org>; Sun, 15 Dec 2013 09:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZIQJWmjCviqMnyw6LB5jfptxPAF1E3hZOudIv9gmAk0=; b=f7Ud1/SgQSYTKu3FD2V9U4RmfTvvIGgbw2HELywmihSjuQOZEFk5Wl8x7XSK+fB7UA y929h0y6PfYIy6Fnl2DiZeNaw0llPcXcAamIHC6KSFLazgWM+y+l8CtOiwGv0gY8wQbM 5A1WMLZyFeaGtt4KQDf84THYsBFG6fhBQ4NAu1qe5k1OVeRM+BrKVOTwryE9az80T9K5 9kWM5q8EkUkNmGkJHrKVgNe1PXe3xMV/DlzRekBUkpN+EsRmEvZZSCPh9pEui0kOsfVg fRKPjxCJpruN3ROTRlBOkPFa1CRAmP6jVeAFyYbaDwC1mL2k3NClbKItsWQlFD1nlZ8D RRbw== MIME-Version: 1.0 X-Received: by 10.180.39.177 with SMTP id q17mr10615338wik.16.1387127840167; Sun, 15 Dec 2013 09:17:20 -0800 (PST) Received: by 10.216.47.129 with HTTP; Sun, 15 Dec 2013 09:17:20 -0800 (PST) In-Reply-To: References: Date: Sun, 15 Dec 2013 19:17:20 +0200 Message-ID: Subject: Re: bug#16039: repeated emacs crashes (in GC?) From: emacs user To: YAMAMOTO Mitsuharu Content-Type: multipart/alternative; boundary=001a11c228d22bdd6904ed95de15 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16039 Cc: Eli Zaretskii , 16039@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c228d22bdd6904ed95de15 Content-Type: text/plain; charset=ISO-8859-1 Dear Eli and Mitsuharu, Please let me know if there is anything else I can do, test patches or such. again, Emacs just does not ever crash for me after the change mentioned below, a great relief. E On Sat, Dec 7, 2013 at 10:29 PM, emacs user wrote: > so after running the same emacs session for 72 hours, during which I used > vm many times and emacs used a total of 1.5 CPU hours, I think it is safe > to say that this problem that caused frequent crashes is fixed by the > increase in newlim as specified below. I hope something like this can be > implemented in the emacs development version. Thanks for your help, best, > E > > > On Thu, Dec 5, 2013 at 8:54 AM, emacs user wrote: > >> I managed to compile your mac port and inserted: >> >> newlim = (re_max_failures * ratio + 200000)*2; >> >> will let you know in a few days if I still see crashes. >> >> >> On Thu, Dec 5, 2013 at 2:35 AM, YAMAMOTO Mitsuharu < >> mituharu@math.s.chiba-u.ac.jp> wrote: >> >>> >>>>> On Wed, 04 Dec 2013 10:48:11 +0900, YAMAMOTO Mitsuharu < >>> mituharu@math.s.chiba-u.ac.jp> said: >>> >>> >>> Having 136 thousand frames during GC is not unheard of. >>> >>> >> (/ 8720000.0 (* 136 1000)) >>> >> 64.11764705882354 >>> >>> >> If each frame consumes more than 64 bytes, then it will use up >>> >> 8720000B stack space. >>> >>> > FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the >>> > -O2 option seems to consume 64 bytes for each mark_object frame: >>> >>> > i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) >>> (dot 3) >>> >>> > _mark_object: >>> > 00000000000008a0 pushq %rbp >>> > 00000000000008a1 movq %rsp, %rbp >>> > 00000000000008a4 movq %rbx, 0xffffffffffffffd8(%rbp) >>> > 00000000000008a8 movq %r12, 0xffffffffffffffe0(%rbp) >>> > 00000000000008ac movq %r13, 0xffffffffffffffe8(%rbp) >>> > 00000000000008b0 movq %r14, 0xfffffffffffffff0(%rbp) >>> > 00000000000008b4 movq %r15, 0xfffffffffffffff8(%rbp) >>> > 00000000000008b8 subq $0x40, %rsp >>> >>> > And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes: >>> >>> > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> > _mark_object: >>> > 0000000000005c70 pushq %rbp >>> > 0000000000005c71 movq %rsp, %rbp >>> > 0000000000005c74 pushq %r15 >>> > 0000000000005c76 pushq %r14 >>> > 0000000000005c78 pushq %r13 >>> > 0000000000005c7a pushq %r12 >>> > 0000000000005c7c pushq %rbx >>> > 0000000000005c7d subq $0x18, %rsp >>> >>> I forgot to count the pushq instructions. The correct value would be >>> 72 bytes for each mark_object frame in both cases. >>> >>> YAMAMOTO Mitsuharu >>> mituharu@math.s.chiba-u.ac.jp >>> >> >> > --001a11c228d22bdd6904ed95de15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Eli and Mitsuharu, Please let me know if there is any= thing else I can do, test patches or such. =A0again, Emacs just does not ev= er crash for me after the change mentioned below, a great relief. =A0E


On Sat, Dec 7, 2013 at 10:29 PM, emacs u= ser <user.emacs@gmail.com> wrote:
so after running the same emacs session for 72 hours, duri= ng which I used vm many times and emacs used a total of 1.5 CPU hours, I th= ink it is safe to say that this problem that caused frequent crashes is fix= ed by the increase in=A0newlim=A0as specified below. I hope something like = this can be implemented in the emacs development version. =A0 Thanks for yo= ur help,=A0best, E


On Thu, Dec 5= , 2013 at 8:54 AM, emacs user <user.emacs@gmail.com> wrot= e:
I managed to compile your mac port and in= serted:

=A0 =A0 =A0 newlim =3D (re_max_failures * ratio + 20000= 0)*2;

will let you know in a few days if I s= till see crashes.


On Thu,= Dec 5, 2013 at 2:35 AM, YAMAMOTO Mitsuharu <mituharu@math.s= .chiba-u.ac.jp> wrote:
>>>>> On Wed, 04 Dec 2013 10:48:11 +0900, Y= AMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> Having 136 thousand frames during GC is not unheard of.

>> (/ 8720000.0 (* 136 1000))
>> 64.11764705882354

>> If each frame consumes more than 64 bytes, then it will use up
>> 8720000B stack space.

> FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the > -O2 option seems to consume 64 bytes for each mark_object frame:

> =A0 i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) = (dot 3)

> =A0 _mark_object:
> =A0 00000000000008a0 =A0 =A0pushq =A0 %rbp
> =A0 00000000000008a1 =A0 =A0movq =A0 =A0%rsp, %rbp
> =A0 00000000000008a4 =A0 =A0movq =A0 =A0%rbx, 0xffffffffffffffd8(%rbp)=
> =A0 00000000000008a8 =A0 =A0movq =A0 =A0%r12, 0xffffffffffffffe0(%rbp)=
> =A0 00000000000008ac =A0 =A0movq =A0 =A0%r13, 0xffffffffffffffe8(%rbp)=
> =A0 00000000000008b0 =A0 =A0movq =A0 =A0%r14, 0xfffffffffffffff0(%rbp)=
> =A0 00000000000008b4 =A0 =A0movq =A0 =A0%r15, 0xfffffffffffffff8(%rbp)=
> =A0 00000000000008b8 =A0 =A0subq =A0 =A0$0x40, %rsp

> And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes:

> =A0 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)

> =A0 _mark_object:
> =A0 0000000000005c70 =A0 =A0pushq =A0 %rbp
> =A0 0000000000005c71 =A0 =A0movq =A0 =A0%rsp, %rbp
> =A0 0000000000005c74 =A0 =A0pushq =A0 %r15
> =A0 0000000000005c76 =A0 =A0pushq =A0 %r14
> =A0 0000000000005c78 =A0 =A0pushq =A0 %r13
> =A0 0000000000005c7a =A0 =A0pushq =A0 %r12
> =A0 0000000000005c7c =A0 =A0pushq =A0 %rbx
> =A0 0000000000005c7d =A0 =A0subq =A0 =A0$0x18, %rsp

I forgot to count the pushq instructions. =A0The correct value would be
72 bytes for each mark_object frame in both cases.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= YAMAMOTO Mitsuharu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mituharu@math.s.chi= ba-u.ac.jp



--001a11c228d22bdd6904ed95de15-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 15 12:45:07 2013 Received: (at 16039) by debbugs.gnu.org; 15 Dec 2013 17:45:08 +0000 Received: from localhost ([127.0.0.1]:51916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VsFkY-0000os-W9 for submit@debbugs.gnu.org; Sun, 15 Dec 2013 12:45:07 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:50993) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VsFkU-0000oP-TZ for 16039@debbugs.gnu.org; Sun, 15 Dec 2013 12:45:04 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MXU00E00ZPE4X00@a-mtaout21.012.net.il> for 16039@debbugs.gnu.org; Sun, 15 Dec 2013 19:45:01 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MXU00ESSZZ00F80@a-mtaout21.012.net.il>; Sun, 15 Dec 2013 19:45:01 +0200 (IST) Date: Sun, 15 Dec 2013 19:45:07 +0200 From: Eli Zaretskii Subject: Re: bug#16039: repeated emacs crashes (in GC?) In-reply-to: X-012-Sender: halo1@inter.net.il To: emacs user Message-id: <83situdn4s.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16039 Cc: 16039@debbugs.gnu.org, mituharu@math.s.chiba-u.ac.jp X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 15 Dec 2013 19:17:20 +0200 > From: emacs user > Cc: Eli Zaretskii , 16039@debbugs.gnu.org > > Dear Eli and Mitsuharu, Please let me know if there is anything else I can > do, test patches or such. again, Emacs just does not ever crash for me > after the change mentioned below, a great relief. E I guess we should commit the change, then. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 11:06:11 2014 Received: (at 16039) by debbugs.gnu.org; 18 Jan 2014 16:06:11 +0000 Received: from localhost ([127.0.0.1]:56302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W4YPS-0002o3-Ka for submit@debbugs.gnu.org; Sat, 18 Jan 2014 11:06:11 -0500 Received: from mail-wi0-f180.google.com ([209.85.212.180]:54254) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W4YPP-0002ns-Mw for 16039@debbugs.gnu.org; Sat, 18 Jan 2014 11:06:08 -0500 Received: by mail-wi0-f180.google.com with SMTP id d13so1822221wiw.7 for <16039@debbugs.gnu.org>; Sat, 18 Jan 2014 08:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1uOkmmPYROPsYRlwl6UWfJPhqMwdOYj57yUMhWzRqSo=; b=WBe8kqrlP8Ad/e81nXV0ZWTx7pur+HDWVElhEABmT9FgieHB9AcX5LMuNXNAb48rXb ceGdCfaGUNE7BSkCewP90XnNb4pL90Nw2wmYGEh9knyO1Xj/yXvXySeP1p3ZvnEZeGCV Ol5e9vt/zrMkpWolkWRF4l/MElaObEWLXyLVpB8h6V+JtpqTJfZdMyaupVzgJRcvjA13 XnwqAMWT5j/6NSqIkpahq8B/L+HHDg8AFkIXV3eZEHBr4kQ1jt+E0BKihlLhgM7GjnRo uVQuuvCBqh9Oqmt0TJ+tQp9Afv6dfMT1R8S9GlDtvaK1DmEDjqtQh1OXqwlWVjIeUlu0 Ecmw== MIME-Version: 1.0 X-Received: by 10.180.160.212 with SMTP id xm20mr3008664wib.33.1390061166921; Sat, 18 Jan 2014 08:06:06 -0800 (PST) Received: by 10.217.90.197 with HTTP; Sat, 18 Jan 2014 08:06:06 -0800 (PST) In-Reply-To: <83situdn4s.fsf@gnu.org> References: <83situdn4s.fsf@gnu.org> Date: Sat, 18 Jan 2014 18:06:06 +0200 Message-ID: Subject: Re: bug#16039: repeated emacs crashes (in GC?) From: emacs user To: Eli Zaretskii Content-Type: multipart/alternative; boundary=047d7b624d34120b9204f040d61f X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16039 Cc: 16039@debbugs.gnu.org, YAMAMOTO Mitsuharu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b624d34120b9204f040d61f Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii wrote: > > Date: Sun, 15 Dec 2013 19:17:20 +0200 > > From: emacs user > > Cc: Eli Zaretskii , 16039@debbugs.gnu.org > > > > Dear Eli and Mitsuharu, Please let me know if there is anything else I > can > > do, test patches or such. again, Emacs just does not ever crash for me > > after the change mentioned below, a great relief. E > > I guess we should commit the change, then. > thanks, that would be good, although perhaps using a more sensible way to increase newlim than I used... best, E --047d7b624d34120b9204f040d61f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii &l= t;eliz@gnu.org> wrote:
> Date: Sun, 15 Dec 2013 19:17:20 +0200 > From: emacs user <user.emac= s@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org= >, 16039@debbugs.gnu.org >
> Dear Eli and Mitsuharu, Please let me know if there is anything else I= can
> do, test patches or such. =A0again, Emacs just does not ever crash for= me
> after the change mentioned below, a great relief. =A0E

I guess we should commit the change, then.

thanks, that would = be good, although perhaps using a more sensible way to=A0increase newlim th= an I used... =A0best, E

--047d7b624d34120b9204f040d61f-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 28 11:08:13 2016 Received: (at 16039) by debbugs.gnu.org; 28 May 2016 15:08:13 +0000 Received: from localhost ([127.0.0.1]:44944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b6fqX-0003e1-BH for submit@debbugs.gnu.org; Sat, 28 May 2016 11:08:13 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:35172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b6fqU-0003do-NE for 16039@debbugs.gnu.org; Sat, 28 May 2016 11:08:11 -0400 Received: by mail-wm0-f49.google.com with SMTP id a136so28641805wme.0 for <16039@debbugs.gnu.org>; Sat, 28 May 2016 08:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=R8+sVc5BWtPjkeKo+k9wka7pxFGWUhpWUJrHkdqCoCs=; b=BCDLLdX1cr4lByxts4t9bbRSCWWUDQaDCYC57C3sBsIBt2FoQiLq3D8d3KvgF03VM7 lDKUPSV/6bQdtmCi4/PGYhB+xqVRCveBQBAqt7YHsXDc01tp7szoMM/Y4dm8uQYEYKij r2TmyhHL9uVoX0vdt3J2qRjXbs5Wg10pRwUCFFtlE8mhAFl8+T2QeC+tI+M3YAJqWmdM p9wK6p5tMBoFrUAiwbdopQ+8Jf3q9TQKLv2gtkJkEkZZKhb9cU1eo36JRYgskq5tc+T8 rti4BtcAxdBIp0/9Mt3QRcbJVJcDyCszvJdB4EtaNnJwaus9NW1utdyU8IQxqiLuLA4V rn9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=R8+sVc5BWtPjkeKo+k9wka7pxFGWUhpWUJrHkdqCoCs=; b=StZUjgsdHXJf+BjDSzGS2PzqrKXU2Vm66Op+kzWWm9F42eGI1ISliVeI0s6bHuny4Q gdHhwoyrstR4m09MDNfKwgBf7puZZ+eKVsPYqgHaVJ4+6dW9gY5aZA5D3ly/LMuw5dDw LPSYa1X4TQ+ZWQ/Jk/tyQFye+m4eDD9hGWTdMHMWYibQ7ZpG2vVfP0DQN4aXfwA7NHlU HBI1r2Rt5q6D5Y8CKQPttMp5jK0b+kiK6k1Cxw9x3qUmPYLbc50cCGdVdv7qjOH0Igfw Dm8TA8AN42MesKfRP+9e/ljcici5IVTH9Sgw/RC3WoWkliIEvVLq2L9c13Le1cQnzpuB x16w== X-Gm-Message-State: ALyK8tID9WuF7AJfd15hKSKBUE/poVmOdR51O5+OlIp9nLa4AQB67/llKw0CSMs5c/WEfA== X-Received: by 10.28.18.11 with SMTP id 11mr3312775wms.51.1464448085121; Sat, 28 May 2016 08:08:05 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-20c5-ff51-aaec-eb15.holly.idiocy.org. [2001:8b0:3f8:8129:20c5:ff51:aaec:eb15]) by smtp.gmail.com with ESMTPSA id f12sm14001024wme.13.2016.05.28.08.08.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 May 2016 08:08:04 -0700 (PDT) From: Alan Third To: emacs user Subject: Re: bug#16039: repeated emacs crashes (in GC?) References: <83situdn4s.fsf@gnu.org> Date: Sat, 28 May 2016 16:08:03 +0100 In-Reply-To: (emacs user's message of "Sat, 18 Jan 2014 18:06:06 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 16039 Cc: Eli Zaretskii , 16039@debbugs.gnu.org, YAMAMOTO Mitsuharu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) emacs user writes: > On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii wrote: > > > Date: Sun, 15 Dec 2013 19:17:20 +0200 > > From: emacs user > > Cc: Eli Zaretskii , 16039@debbugs.gnu.org > > > > Dear Eli and Mitsuharu, Please let me know if there is anything else I can > > do, test patches or such. again, Emacs just does not ever crash for me > > after the change mentioned below, a great relief. E > > I guess we should commit the change, then. > > thanks, that would be good, although perhaps using a more sensible way to increase newlim than I used... best, E Hi, as far as I can tell this change was never made. Are you still using a patched version of Emacs? Some changes were made recently to the handling of the stack on OS X and I'm curious if they fix these random stack overflows. (Or if they'd gone away before now anyway?) -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 03 18:45:44 2016 Received: (at 16039) by debbugs.gnu.org; 3 Nov 2016 22:45:44 +0000 Received: from localhost ([127.0.0.1]:41962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c2QlT-0000Sd-Pu for submit@debbugs.gnu.org; Thu, 03 Nov 2016 18:45:44 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:35600) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c2QlS-0000SQ-3D for 16039@debbugs.gnu.org; Thu, 03 Nov 2016 18:45:42 -0400 Received: by mail-wm0-f41.google.com with SMTP id a197so16452486wmd.0 for <16039@debbugs.gnu.org>; Thu, 03 Nov 2016 15:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cJyRlsVkI3uyGL4+Zc/SlwTzfZkhAnayqgUMZkpr/wY=; b=ThnVktld+TBR/A73D3dIvEPfC1VS0Lc244OT0uYv6oVe+zr+8vM0t+mXhbg8xOKxcJ /YMGup8NDNkzf2oPdbE/phqR+FHq80x7GeQ1J68c+8YNK7/Ro2+V9zfCoxcbGLor/hY4 tqnzN+dUINfPvqN2IQvUsZQXxBZUzPWkFN6b8cCdTPXpjM5wSKZKZyOABr4RjTwjS2me +E19vOenxmU1cj5WI/7pI9ytoXmUJm4LMmV+MFxFOs+hst1anKwhR0syxkg3lFKTZ4DZ bArLUYtC+yEAS4Vgwjsh2swMnkEzs4G8H3ZmSF+ZVf2AqeUHor+sjYftk0IuHcTFr2RX Qfpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cJyRlsVkI3uyGL4+Zc/SlwTzfZkhAnayqgUMZkpr/wY=; b=U8BOhKCcPJsV3MrOJ4ICtyrx32wdemSj4A3jPpfIxSLxSg23SuEix1pbhkFWHgSGSx 7jIqp1WJUDcjEAlLxvVh0Tia3yj5Pdc55cSuZNMq38iBQ92sd5RdK7t64IH9x3sSVEoy u0CqynWvgbdUJSJueFogdaXFl7j2kVduh/AnjlyZRTL0Abq0jyxlPOrzJyneA2XiVJcd ePGSc2uyM3HaSuDTZu4baCK2U+pD696ywQ/owFRq3DOeMGHZV/w3KDQgth5sgC3xh3wM IuM3n/7bGuOjLGQ8xL//w7c55ohialJHvq12PdyKEnBBG2LH7e5EzU5yd+So5pVTEAlS tWwg== X-Gm-Message-State: ABUngvf1Jc5Ic0+QNYjvZIAjle65wsnbB6dQG+9Olib4NTzcR3H5/JXY20df0mtM8mLHsJum/G/E6TPvO1bYKQ== X-Received: by 10.28.13.144 with SMTP id 138mr294306wmn.41.1478213136272; Thu, 03 Nov 2016 15:45:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.172.110 with HTTP; Thu, 3 Nov 2016 15:45:35 -0700 (PDT) In-Reply-To: References: <83situdn4s.fsf@gnu.org> From: emacs user Date: Fri, 4 Nov 2016 00:45:35 +0200 Message-ID: Subject: Re: bug#16039: repeated emacs crashes (in GC?) To: Alan Third Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 16039 Cc: Eli Zaretskii , 16039@debbugs.gnu.org, YAMAMOTO Mitsuharu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) I stopped using emacs for email (vm) and am therefore not running into this problem again and do not need the patched version. best, E On Sat, May 28, 2016 at 6:08 PM, Alan Third wrote: > emacs user writes: > >> On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii wrote: >> >> > Date: Sun, 15 Dec 2013 19:17:20 +0200 >> > From: emacs user >> > Cc: Eli Zaretskii , 16039@debbugs.gnu.org >> > >> > Dear Eli and Mitsuharu, Please let me know if there is anything else I can >> > do, test patches or such. again, Emacs just does not ever crash for me >> > after the change mentioned below, a great relief. E >> >> I guess we should commit the change, then. >> >> thanks, that would be good, although perhaps using a more sensible way to increase newlim than I used... best, E > > Hi, as far as I can tell this change was never made. Are you still using > a patched version of Emacs? > > Some changes were made recently to the handling of the stack on OS X and > I'm curious if they fix these random stack overflows. (Or if they'd gone > away before now anyway?) > > -- > Alan Third From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 11 14:11:15 2016 Received: (at control) by debbugs.gnu.org; 11 Nov 2016 19:11:15 +0000 Received: from localhost ([127.0.0.1]:54255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c5HEI-00060b-IE for submit@debbugs.gnu.org; Fri, 11 Nov 2016 14:11:15 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:36459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c5HEG-00060K-V1 for control@debbugs.gnu.org; Fri, 11 Nov 2016 14:11:13 -0500 Received: by mail-wm0-f47.google.com with SMTP id g23so114681219wme.1 for ; Fri, 11 Nov 2016 11:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:date:message-id:to:from:subject; bh=oaum6d+gRVVSf32fzuBb5JEpBe2N+n3YGb/xFxhUi6s=; b=VGOTOK1yYBGrMw3uQ05Ks8J07CWlc5C23DHhHdFjM1rr68hTrkzJsrOQITJ63ksQrM GZPV1v9hj+a35IvA+wvL+El1rkFRWw28qB/G7/8Zio9W39suLaTaT9k6G4qhufzWGxfi ConrESByReNHAD1tAQqBIYtispEu6nj16P2CtKKUjW9D7zJQMvAFUbQvS6XC9yhmSeTN 131aQ++M1mnQH3PQ8ntyb6egYEzFYRpqgS2RJsKDvz7oUOjkQAC/TyGcu30ORP1y/gWG L75p3CgaMwz26idq/69uUjBnEfbweQqnN8hx1g6Fpp07sl0Pxi1J/gthjRT5ExzeZwn2 JPUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:message-id:to:from:subject; bh=oaum6d+gRVVSf32fzuBb5JEpBe2N+n3YGb/xFxhUi6s=; b=JuJLomY/y/L+udlbFA4tnc/lE/NOFv9gePBtKGlrJqMWgJ3nOb+V7fqIjMRIeI9NOb SBXbENP+/6RzsU604ca16XU9kIcSonBg3uVoA+P2SdtX2Vsu1XaFjnWwCU7xMjX09Chf JoxMpQHtIXoCyFMLddDI41uP8JRhkNttFWdwuTsNlRgFa6Kd/YBiEiFhVcEW+VzpHWLh QB15JYsuny+DJO+6j4Z/aqcd9kPBetQmjije99gIfZzafwHiTHzUNiXzozCtMkibsMyE bVkEG+YPMYrlLEikZ/fdhF2z8CRVZleUPLPR5HVmqEJb0w2gJw19dMqRMKKHejLzT/iM LN7Q== X-Gm-Message-State: ABUngvdC7LemiqzeKdwau0d9j2Kwvfj2UmZwrGUsWOGRn9qqPvNbSMJVuaWRqPfXhO6ysw== X-Received: by 10.194.0.229 with SMTP id 5mr12517800wjh.55.1478891467261; Fri, 11 Nov 2016 11:11:07 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-691f-63c2-3f2c-99a8.holly.idiocy.org. [2001:8b0:3f8:8129:691f:63c2:3f2c:99a8]) by smtp.gmail.com with ESMTPSA id j6sm12959096wjk.25.2016.11.11.11.11.06 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 11 Nov 2016 11:11:06 -0800 (PST) Date: Fri, 11 Nov 2016 19:11:06 +0000 Message-Id: To: control@debbugs.gnu.org From: Alan Third Subject: control message for bug #16039 X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) tags 16039 fixed close 16039 25.2 From unknown Tue Jun 17 03:38:05 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 10 Dec 2016 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator