* bug#16039: repeated emacs crashes (in GC?)
@ 2013-12-03 14:55 emacs user
2013-12-03 16:01 ` Eli Zaretskii
2013-12-07 20:29 ` emacs user
0 siblings, 2 replies; 14+ messages in thread
From: emacs user @ 2013-12-03 14:55 UTC (permalink / raw)
To: 16039
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#16039: repeated emacs crashes (in GC?)
2013-12-03 14:55 bug#16039: repeated emacs crashes (in GC?) emacs user
@ 2013-12-03 16:01 ` Eli Zaretskii
2013-12-04 0:43 ` YAMAMOTO Mitsuharu
2013-12-07 20:29 ` emacs user
1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2013-12-03 16:01 UTC (permalink / raw)
To: emacs user; +Cc: 16039
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-03 16:01 ` Eli Zaretskii
@ 2013-12-04 0:43 ` YAMAMOTO Mitsuharu
2013-12-04 1:48 ` YAMAMOTO Mitsuharu
2013-12-04 3:49 ` Eli Zaretskii
0 siblings, 2 replies; 14+ messages in thread
From: YAMAMOTO Mitsuharu @ 2013-12-04 0:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16039, emacs user
>>>>> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-04 0:43 ` YAMAMOTO Mitsuharu
@ 2013-12-04 1:48 ` YAMAMOTO Mitsuharu
2013-12-05 0:35 ` YAMAMOTO Mitsuharu
2013-12-04 3:49 ` Eli Zaretskii
1 sibling, 1 reply; 14+ messages in thread
From: YAMAMOTO Mitsuharu @ 2013-12-04 1:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16039, emacs user
>>>>> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-04 1:48 ` YAMAMOTO Mitsuharu
@ 2013-12-05 0:35 ` YAMAMOTO Mitsuharu
2013-12-05 6:54 ` emacs user
0 siblings, 1 reply; 14+ messages in thread
From: YAMAMOTO Mitsuharu @ 2013-12-05 0:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16039, emacs user
>>>>> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-05 0:35 ` YAMAMOTO Mitsuharu
@ 2013-12-05 6:54 ` emacs user
0 siblings, 0 replies; 14+ messages in thread
From: emacs user @ 2013-12-05 6:54 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: 16039
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-04 0:43 ` YAMAMOTO Mitsuharu
2013-12-04 1:48 ` YAMAMOTO Mitsuharu
@ 2013-12-04 3:49 ` Eli Zaretskii
2013-12-04 6:33 ` emacs user
1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2013-12-04 3:49 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: 16039, user.emacs
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-04 3:49 ` Eli Zaretskii
@ 2013-12-04 6:33 ` emacs user
0 siblings, 0 replies; 14+ messages in thread
From: emacs user @ 2013-12-04 6:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16039
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-03 14:55 bug#16039: repeated emacs crashes (in GC?) emacs user
2013-12-03 16:01 ` Eli Zaretskii
@ 2013-12-07 20:29 ` emacs user
2013-12-15 17:17 ` emacs user
1 sibling, 1 reply; 14+ messages in thread
From: emacs user @ 2013-12-07 20:29 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: 16039
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-07 20:29 ` emacs user
@ 2013-12-15 17:17 ` emacs user
2013-12-15 17:45 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: emacs user @ 2013-12-15 17:17 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: 16039
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-15 17:17 ` emacs user
@ 2013-12-15 17:45 ` Eli Zaretskii
2014-01-18 16:06 ` emacs user
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2013-12-15 17:45 UTC (permalink / raw)
To: emacs user; +Cc: 16039
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2013-12-15 17:45 ` Eli Zaretskii
@ 2014-01-18 16:06 ` emacs user
2016-05-28 15:08 ` Alan Third
0 siblings, 1 reply; 14+ messages in thread
From: emacs user @ 2014-01-18 16:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16039
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2014-01-18 16:06 ` emacs user
@ 2016-05-28 15:08 ` Alan Third
2016-11-03 22:45 ` emacs user
0 siblings, 1 reply; 14+ messages in thread
From: Alan Third @ 2016-05-28 15:08 UTC (permalink / raw)
To: emacs user; +Cc: 16039
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16039: repeated emacs crashes (in GC?)
2016-05-28 15:08 ` Alan Third
@ 2016-11-03 22:45 ` emacs user
0 siblings, 0 replies; 14+ messages in thread
From: emacs user @ 2016-11-03 22:45 UTC (permalink / raw)
To: Alan Third; +Cc: 16039
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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-11-03 22:45 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-03 14:55 bug#16039: repeated emacs crashes (in GC?) emacs user
2013-12-03 16:01 ` Eli Zaretskii
2013-12-04 0:43 ` YAMAMOTO Mitsuharu
2013-12-04 1:48 ` YAMAMOTO Mitsuharu
2013-12-05 0:35 ` YAMAMOTO Mitsuharu
2013-12-05 6:54 ` emacs user
2013-12-04 3:49 ` Eli Zaretskii
2013-12-04 6:33 ` emacs user
2013-12-07 20:29 ` emacs user
2013-12-15 17:17 ` emacs user
2013-12-15 17:45 ` Eli Zaretskii
2014-01-18 16:06 ` emacs user
2016-05-28 15:08 ` Alan Third
2016-11-03 22:45 ` emacs user
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).