GNU bug report logs -
#16039
repeated emacs crashes (in GC?)
Previous Next
Reported by: emacs user <user.emacs <at> gmail.com>
Date: Tue, 3 Dec 2013 14:57:02 UTC
Severity: normal
Tags: fixed
Fixed in version 25.2
Done: Alan Third <alan <at> idiocy.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16039 in the body.
You can then email your comments to 16039 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Tue, 03 Dec 2013 14:57:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
emacs user <user.emacs <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 03 Dec 2013 14:57:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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:~ $
------------------------------------------------------------------------
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Tue, 03 Dec 2013 16:02:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 16039 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 3 Dec 2013 16:55:43 +0200
> From: emacs user <user.emacs <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Wed, 04 Dec 2013 00:44:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 16039 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 03 Dec 2013 18:01:21 +0200, Eli Zaretskii <eliz <at> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Wed, 04 Dec 2013 01:49:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 16039 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 04 Dec 2013 09:43:00 +0900, YAMAMOTO Mitsuharu <mituharu <at> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Wed, 04 Dec 2013 03:50:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 16039 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 04 Dec 2013 09:43:00 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: emacs user <user.emacs <at> gmail.com>,
> 16039 <at> debbugs.gnu.org
>
> >>>>> On Tue, 03 Dec 2013 18:01:21 +0200, Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Wed, 04 Dec 2013 06:34:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 16039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Dec 4, 2013 at 5:49 AM, Eli Zaretskii <eliz <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Thu, 05 Dec 2013 00:36:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 16039 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 04 Dec 2013 10:48:11 +0900, YAMAMOTO Mitsuharu <mituharu <at> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Thu, 05 Dec 2013 06:55:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 16039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> math.s.chiba-u.ac.jp> wrote:
> >>>>> On Wed, 04 Dec 2013 10:48:11 +0900, YAMAMOTO Mitsuharu <
> mituharu <at> 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 <at> math.s.chiba-u.ac.jp
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Sat, 07 Dec 2013 20:30:03 GMT)
Full text and
rfc822 format available.
Message #29 received at 16039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> math.s.chiba-u.ac.jp> wrote:
>
>> >>>>> On Wed, 04 Dec 2013 10:48:11 +0900, YAMAMOTO Mitsuharu <
>> mituharu <at> 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 <at> math.s.chiba-u.ac.jp
>>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Sun, 15 Dec 2013 17:18:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 16039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> 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 <at> math.s.chiba-u.ac.jp> wrote:
>>
>>> >>>>> On Wed, 04 Dec 2013 10:48:11 +0900, YAMAMOTO Mitsuharu <
>>> mituharu <at> 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 <at> math.s.chiba-u.ac.jp
>>>
>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Sun, 15 Dec 2013 17:46:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 16039 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 15 Dec 2013 19:17:20 +0200
> From: emacs user <user.emacs <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 16039 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Sat, 18 Jan 2014 16:07:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 16039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Date: Sun, 15 Dec 2013 19:17:20 +0200
> > From: emacs user <user.emacs <at> gmail.com>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 16039 <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Sat, 28 May 2016 15:09:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 16039 <at> debbugs.gnu.org (full text, mbox):
emacs user <user.emacs <at> gmail.com> writes:
> On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Date: Sun, 15 Dec 2013 19:17:20 +0200
> > From: emacs user <user.emacs <at> gmail.com>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 16039 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16039; Package
emacs.
(Thu, 03 Nov 2016 22:46:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 16039 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org> wrote:
> emacs user <user.emacs <at> gmail.com> writes:
>
>> On Sun, Dec 15, 2013 at 7:45 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> > Date: Sun, 15 Dec 2013 19:17:20 +0200
>> > From: emacs user <user.emacs <at> gmail.com>
>> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 16039 <at> 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
Added tag(s) fixed.
Request was from
Alan Third <alan <at> idiocy.org>
to
control <at> debbugs.gnu.org.
(Fri, 11 Nov 2016 19:12:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 25.2, send any further explanations to
16039 <at> debbugs.gnu.org and emacs user <user.emacs <at> gmail.com>
Request was from
Alan Third <alan <at> idiocy.org>
to
control <at> debbugs.gnu.org.
(Fri, 11 Nov 2016 19:12:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 10 Dec 2016 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 189 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.