bug#16039: repeated emacs crashes (in GC?)

bug#16039: repeated emacs crashes (in GC?)

[emacs user]

[-- Attachment #1: Type: text/plain, Size: 15793 bytes --]

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:~ $
------------------------------------------------------------------------

[-- Attachment #2: Type: text/html, Size: 19176 bytes --]

bug#16039: repeated emacs crashes (in GC?)

[Eli Zaretskii]

> Date: Tue, 3 Dec 2013 16:55:43 +0200
> From: emacs user <user.emacs@gmail.com>
> 
> 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.

bug#16039: repeated emacs crashes (in GC?)

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 03 Dec 2013 18:01:21 +0200, Eli Zaretskii <eliz@gnu.org> 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

bug#16039: repeated emacs crashes (in GC?)

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 04 Dec 2013 09:43:00 +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

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

bug#16039: repeated emacs crashes (in GC?)

[Eli Zaretskii]

> Date: Wed, 04 Dec 2013 09:43:00 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs user <user.emacs@gmail.com>,
> 	16039@debbugs.gnu.org
> 
> >>>>> On Tue, 03 Dec 2013 18:01:21 +0200, Eli Zaretskii <eliz@gnu.org> 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.

bug#16039: repeated emacs crashes (in GC?)

[emacs user]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

On Wed, Dec 4, 2013 at 5:49 AM, Eli Zaretskii <eliz@gnu.org> 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

[-- Attachment #2: Type: text/html, Size: 743 bytes --]

bug#16039: repeated emacs crashes (in GC?)

[YAMAMOTO Mitsuharu]

>>>>> 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

bug#16039: repeated emacs crashes (in GC?)

[emacs user]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2812 bytes --]

bug#16039: repeated emacs crashes (in GC?)

[emacs user]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

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 <user.emacs@gmail.com> 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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3708 bytes --]

bug#16039: repeated emacs crashes (in GC?)

[emacs user]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

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 <user.emacs@gmail.com> 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 <user.emacs@gmail.com> 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
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4297 bytes --]

bug#16039: repeated emacs crashes (in GC?)

[Eli Zaretskii]

> Date: Sun, 15 Dec 2013 19:17:20 +0200
> From: emacs user <user.emacs@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.  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.

bug#16039: repeated emacs crashes (in GC?)

[emacs user]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 15 Dec 2013 19:17:20 +0200
> > From: emacs user <user.emacs@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.  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

[-- Attachment #2: Type: text/html, Size: 1137 bytes --]

bug#16039: repeated emacs crashes (in GC?)

[Alan Third]

emacs user <user.emacs@gmail.com> writes:

> On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>  > Date: Sun, 15 Dec 2013 19:17:20 +0200
>  > From: emacs user <user.emacs@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. 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

bug#16039: repeated emacs crashes (in GC?)

[emacs user]

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 <alan@idiocy.org> wrote:
> emacs user <user.emacs@gmail.com> writes:
>
>> On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>  > Date: Sun, 15 Dec 2013 19:17:20 +0200
>>  > From: emacs user <user.emacs@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. 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