Package: emacs;
Reported by: sds <at> gnu.org
Date: Mon, 12 Sep 2022 14:38:01 UTC
Severity: normal
Found in version 29.0.50
Fixed in version 29.1
Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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 57751 in the body.
You can then email your comments to 57751 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Mon, 12 Sep 2022 14:38:01 GMT) Full text and rfc822 format available.sds <at> gnu.org:bug-gnu-emacs <at> gnu.org.
(Mon, 12 Sep 2022 14:38:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: bug-gnu-emacs <at> gnu.org Subject: 29.0.50; crash in GC Date: Mon, 12 Sep 2022 10:37:17 -0400
About a week ago Emacs crashed and now it consistently crashes on
startup if I agree to load the desktop file from the crashed session.
If I refuse to load the desktop file and instead load files on-by-one, I
also eventually (an hour or a day later) get a crash, albeit I do get
some work done in the meantime.
I did a few `git pull && make bootstrap` (the latest this morning) in
the vain (so far) hope that the problem disappears.
Here is the backtrace:
--8<---------------cut here---------------start------------->8---
(lldb) run
Process 73681 launched: '/Users/sdsg/src/emacs/build/src/emacs' (x86_64)
2022-09-12 10:08:57.646156-0400 emacs[73681:5354078] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=73681
2022-09-12 10:08:57.646250-0400 emacs[73681:5354078] SecTaskCopyDebugDescription: emacs[73681]/0#-1 LF=0
2022-09-12 10:08:58.324343-0400 emacs[73681:5354078] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=73681
2022-09-12 10:08:58.324465-0400 emacs[73681:5354078] SecTaskCopyDebugDescription: emacs[73681]/0#-1 LF=0
2022-09-12 10:08:59.202869-0400 emacs[73681:5354078] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=73681
2022-09-12 10:08:59.202981-0400 emacs[73681:5354078] SecTaskCopyDebugDescription: emacs[73681]/0#-1 LF=0
2022-09-12 10:08:59.203719-0400 emacs[73681:5354078] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=73681
2022-09-12 10:08:59.203806-0400 emacs[73681:5354078] SecTaskCopyDebugDescription: emacs[73681]/0#-1 LF=0
2022-09-12 10:09:00.482046-0400 emacs[73681:5354078] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=73681
2022-09-12 10:09:00.482123-0400 emacs[73681:5354078] SecTaskCopyDebugDescription: emacs[73681]/0#-1 LF=0
2022-09-12 10:09:00.482929-0400 emacs[73681:5354078] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=73681
2022-09-12 10:09:00.482997-0400 emacs[73681:5354078] SecTaskCopyDebugDescription: emacs[73681]/0#-1 LF=0
emacs was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 73681 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x0000000100154d30 emacs`process_mark_stack(base_sp=0) at alloc.c:7013:14 [opt]
7010 "cold" and do not have mark bits. */
7011 if (pdumper_object_p (XFLOAT (obj)))
7012 eassert (pdumper_cold_object_p (XFLOAT (obj)));
-> 7013 else if (!XFLOAT_MARKED_P (XFLOAT (obj)))
7014 XFLOAT_MARK (XFLOAT (obj));
7015 break;
7016
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x0000000100154d30 emacs`process_mark_stack(base_sp=0) at alloc.c:7013:14 [opt]
frame #1: 0x0000000100154753 emacs`mark_object(obj=<unavailable>) at alloc.c:7035:3 [opt] [artificial]
frame #2: 0x00000001000fc810 emacs`mark_kboards at keyboard.c:13266:4 [opt]
frame #3: 0x0000000100153c6e emacs`garbage_collect at alloc.c:6187:3 [opt]
frame #4: 0x0000000100153593 emacs`maybe_garbage_collect at alloc.c:6090:5 [opt] [artificial]
frame #5: 0x000000010017d113 emacs`eval_sub [inlined] maybe_gc at lisp.h:5564:5 [opt]
frame #6: 0x000000010017d101 emacs`eval_sub(form=0x0000000102a1cd73) at eval.c:2423 [opt]
frame #7: 0x00000001001ae239 emacs`readevalloop(readcharfun=0x0000000000007470, infile0=0x00007ff7bfefe8d8, sourcename=0x0000000101fcc354, printflag=false, unibyte=<unavailable>, readfun=0x0000000000000000, start=0x0000000000000000, end=0x0000000000000000) at lread.c:2339:15 [opt]
frame #8: 0x00000001001ac3b4 emacs`Fload(file=<unavailable>, noerror=0x0000000000000000, nomessage=<unavailable>, nosuffix=0x0000000000000000, must_suffix=<unavailable>) at lread.c:0:9 [opt]
frame #9: 0x00000001001ae4cd emacs`save_match_data_load(file=<unavailable>, noerror=<unavailable>, nomessage=<unavailable>, nosuffix=<unavailable>, must_suffix=<unavailable>) at lread.c:1630:24 [opt]
frame #10: 0x0000000100180182 emacs`Fautoload_do_load [inlined] load_with_autoload_queue(file=<unavailable>, noerror=0x0000000000000000, nomessage=<unavailable>, nosuffix=0x0000000000000000, must_suffix=<unavailable>) at eval.c:2301:7 [opt]
frame #11: 0x00000001001800e9 emacs`Fautoload_do_load(fundef=0x000000010254ff53, funname=0x00000000018f98d0, macro_only=<unavailable>) at eval.c:2347 [opt]
frame #12: 0x0000000100183692 emacs`funcall_subr(subr=0x00000001002c7350, numargs=2, args=<unavailable>) at eval.c:3056:15 [opt]
frame #13: 0x00000001001ce200 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=2, args=<unavailable>) at bytecode.c:809:14 [opt]
frame #14: 0x0000000100183ca7 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3101:10 [opt] [artificial]
frame #15: 0x000000010018354d emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:0 [opt] [artificial]
frame #16: 0x000000010017fb1c emacs`Ffuncall(nargs=<unavailable>, args=0x0000000105800388) at eval.c:3014:21 [opt]
frame #17: 0x00000001001ce200 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=2, args=<unavailable>) at bytecode.c:809:14 [opt]
frame #18: 0x0000000100183ca7 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3101:10 [opt] [artificial]
frame #19: 0x000000010018354d emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:0 [opt] [artificial]
frame #20: 0x00000001001ce0e0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=0, args=<unavailable>) at bytecode.c:811:14 [opt]
frame #21: 0x0000000100183ca7 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3101:10 [opt] [artificial]
frame #22: 0x0000000100182456 emacs`apply_lambda(fun=0x00000001039bfd05, args=<unavailable>, count=(bytes = 128)) at eval.c:3123:9 [opt]
frame #23: 0x000000010017d50c emacs`eval_sub(form=<unavailable>) at eval.c:0 [opt]
frame #24: 0x000000010018220e emacs`Feval(form=0x00000001042c17d3, lexical=<unavailable>) at eval.c:2375:28 [opt]
frame #25: 0x00000001000fc8a5 emacs`top_level_2 at keyboard.c:1141:10 [opt] [artificial]
frame #26: 0x00000001001808d4 emacs`internal_condition_case(bfun=(emacs`top_level_2 at keyboard.c:1140), handlers=<unavailable>, hfun=(emacs`cmd_error at keyboard.c:935)) at eval.c:1497:25 [opt]
frame #27: 0x00000001000fc85d emacs`top_level_1(ignore=0x0000000000000000) at keyboard.c:1149:5 [opt]
frame #28: 0x000000010018026a emacs`internal_catch(tag=<unavailable>, func=(emacs`top_level_1 at keyboard.c:1146), arg=0x0000000000000000) at eval.c:1220:25 [opt]
frame #29: 0x00000001002643d6 emacs`recursive_edit_1.cold.1 at keyboard.c:1109:2 [opt]
frame #30: 0x00000001000e7779 emacs`recursive_edit_1 [inlined] command_loop at keyboard.c:1107:5 [opt]
frame #31: 0x00000001000e7774 emacs`recursive_edit_1 at keyboard.c:719 [opt]
frame #32: 0x00000001000e78f8 emacs`Frecursive_edit at keyboard.c:802:3 [opt]
frame #33: 0x00000001000e6823 emacs`main(argc=<unavailable>, argv=<unavailable>) at emacs.c:2517:3 [opt]
frame #34: 0x000000010092d52e dyld`start + 462
(lldb) up
frame #1: 0x0000000100154753 emacs`mark_object(obj=<unavailable>) at alloc.c:7035:3 [opt] [artificial]
7032 {
7033 ptrdiff_t sp = mark_stk.sp;
7034 mark_stack_push_value (obj);
-> 7035 process_mark_stack (sp);
7036 }
7037
7038 void
(lldb) up
frame #2: 0x00000001000fc810 emacs`mark_kboards at keyboard.c:13266:4 [opt]
13263 mark_object (event->ie.x);
13264 mark_object (event->ie.y);
13265 mark_object (event->ie.frame_or_window);
-> 13266 mark_object (event->ie.arg);
13267
13268 /* This should never be allocated for a single event, but
13269 mark it anyway in the situation where the list of devices
(lldb) up
frame #3: 0x0000000100153c6e emacs`garbage_collect at alloc.c:6187:3 [opt]
6184 mark_pinned_symbols ();
6185 mark_lread ();
6186 mark_terminals ();
-> 6187 mark_kboards ();
6188 mark_threads ();
6189 #ifdef HAVE_PGTK
6190 mark_pgtkterm ();
(lldb)
--8<---------------cut here---------------end--------------->8---
the "good" part is that, apparently, I can reproduce the crash on demand.
the bad part is that it, apparently, requires my extensive .emacs.
Moreover, `emacs -Q` and loading .emacs and desktop by hand do _not_
produce the crash.
Moreover, the specific desktop file doesn't really matter either.
Please tell me if there anything else I can do.
Thank you.
In GNU Emacs 29.0.50 (build 2, x86_64-apple-darwin21.6.0, NS
appkit-2113.60 Version 12.5.1 (Build 21G83)) of 2022-09-12 built on
3c22fb11fdab.ant.amazon.com
Repository revision: 82530902931416603340feb32cb186173ec2d46d
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2113
System Description: macOS 12.5.1
Configured using:
'configure --with-imagemagick --with-mailutils --with-ns
PKG_CONFIG_PATH='
Configured features:
ACL GIF GMP GNUTLS IMAGEMAGICK JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
KQUEUE NS PDUMPER PNG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP ZLIB
Important settings:
value of $LANG: C
locale-coding-system: utf-8-unix
Major mode: ELisp/d
Minor modes in effect:
shell-dirtrack-mode: t
remember-notes-mode: t
global-edit-server-edit-mode: t
winner-mode: t
which-function-mode: t
url-handler-mode: t
desktop-save-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
column-number-mode: t
line-number-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
abbrev-mode: t
Load-path shadows:
None found.
Features:
(shadow sort bbdb-message mailalias cookie1 flyspell ispell
display-fill-column-indicator mail-extr gnus-msg gnus-art mm-uu mml2015
mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku
url-file svg dom browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud
nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range
gnus-win emacsbug message mailcap yank-media puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config mm-decode
mm-bodies mm-encode mail-parse rfc2231 gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums add-log vc-hg vc-git diff-mode easy-mmode
vc-bzr vc-dispatcher tramp-cache time-stamp tramp-sh tramp
tramp-loaddefs trampver tramp-integration cus-edit pp cus-start files-x
tramp-compat rx shell pcomplete comint ansi-color parse-time iso8601
ls-lisp format-spec remember midnight warnings icons gnus nnheader
gnus-util text-property-search time-date mail-utils range mm-util
mail-prsvr wid-edit bbdb-mua bbdb-com crm mailabbrev bbdb bbdb-site
timezone modus-vivendi-theme modus-themes pcase edit-server advice
server winner ring which-func imenu edebug debug backtrace help-mode
find-func url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile
cconv url-vars help-at-pt desktop frameset cl-loaddefs cl-lib cus-load
info bbdb-autoloads edit-server-autoloads ein-autoloads elpy-autoloads
company-autoloads fb2-reader-autoloads async-autoloads f-autoloads
dash-autoloads markdown-mode-autoloads polymode-autoloads
request-autoloads s-autoloads websearch-autoloads with-editor-autoloads
compat-autoloads yaml-mode-autoloads yasnippet-snippets-autoloads rmc
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads kqueue
cocoa ns lcms2 multi-tty make-network-process emacs)
Memory information:
((conses 16 366335 22931)
(symbols 48 22356 0)
(strings 32 182729 8975)
(string-bytes 1 4526991)
(vectors 16 57705)
(vector-slots 8 822143 10079)
(floats 8 282 104)
(intervals 56 530 11)
(buffers 1000 14))
--
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://www.dhimmitude.org https://jij.org https://fairforall.org
Complete tolerance is impossible: it is insulting to bigots.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Tue, 13 Sep 2022 05:22:01 GMT) Full text and rfc822 format available.Message #8 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Tue, 13 Sep 2022 07:20:58 +0200
[Message part 1 (text/plain, inline)]
Hi Sam, Sam Steingold <sds <at> gnu.org> writes: > About a week ago Emacs crashed and now it consistently crashes on > startup if I agree to load the desktop file from the crashed session. > If I refuse to load the desktop file and instead load files on-by-one, I > also eventually (an hour or a day later) get a crash, albeit I do get > some work done in the meantime. > I did a few `git pull && make bootstrap` (the latest this morning) in > the vain (so far) hope that the problem disappears. Ok. > (lldb) run > Process 73681 launched: '/Users/sdsg/src/emacs/build/src/emacs' (x86_64) > 2022-09-12 10:08:57.646156-0400 emacs[73681:5354078] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=73681 > 2022-09-12 10:08:57.646250-0400 emacs[73681:5354078] > SecTaskCopyDebugDescription: emacs[73681]/0#-1 LF=0 These messages are a bit strange, I've never seen them in my system. But since they don't seem to affect LLDB, I guess we can ignore them. > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) > frame #0: 0x0000000100154d30 emacs`process_mark_stack(base_sp=0) at alloc.c:7013:14 [opt] > 7010 "cold" and do not have mark bits. */ > 7011 if (pdumper_object_p (XFLOAT (obj))) > 7012 eassert (pdumper_cold_object_p (XFLOAT (obj))); > -> 7013 else if (!XFLOAT_MARKED_P (XFLOAT (obj))) > 7014 XFLOAT_MARK (XFLOAT (obj)); > 7015 break; > 7016 > Target 0: (emacs) stopped. Looks like a heap corruption to me, which is detected during a GC that is done while autoloading something. > the "good" part is that, apparently, I can reproduce the crash on > demand. Ok. How boring ;-) > Please tell me if there anything else I can do. I'd start by running an Emacs with address sanitizer enabled. If that doesn't show something, I guess we have to git bisect to find the culprit. But I recommend trying with ASAN first, that has proven itself very useful in the past. I've written me a zsh shell script for that and other purposes which I attach. The important command line option of that script is --asan which configures Emacs with the right CFLAGS and LDFLAGS. There are a number of other command line options you might find useful, please see the script, or invoke it with --help. (If you use it for building Emacs, you'll need to "brew install bear", or remove the call to bear in the script. Also, you might want to use --elc if you don't use native compilatin.) In our case you would just do make-emacs --asan somewhere in your Git worktree. That builds a clean Emacs in-tree with ASAN enabled. Caution: it does a git clean -xdf by default. You then run that Emacs in LLDB cd src lldb emacs Please start Emacs from src because LLDB then picks up the (limited) LLDB support for debugging Emacs that we have in etc/emacs_lldb.py. When ASAN finds a problem, it stops the debugger, and we can look around.
[make-emacs (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Tue, 13 Sep 2022 14:52:02 GMT) Full text and rfc822 format available.Message #11 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Tue, 13 Sep 2022 10:51:12 -0400
Hi Gerd,
Thank you for such an informative reply.
> * Gerd Möllmann <treq.zbryyznaa <at> tznvy.pbz> [2022-09-13 07:20:58 +0200]:
>
> (If you use it for building Emacs, you'll need to "brew install bear",
> or remove the call to bear in the script. Also, you might want to use
> --elc if you don't use native compilatin.)
I think native compilation is disabled on mac by default.
> make-emacs --asan
I build my normal Emacs out of the tree, so the source tree is already
clean, thus I just did
--8<---------------cut here---------------start------------->8---
./autogen.sh
./configure LDFLAGS="-fsanitize=address -fno-omit-frame-pointer" CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer"
--8<---------------cut here---------------end--------------->8---
which produced
--8<---------------cut here---------------start------------->8---
Configured for 'x86_64-apple-darwin21.6.0'.
Where should the build process find the source code? .
What compiler should emacs be built with? gcc -g -O0 -fsanitize=address -fno-omit-frame-pointer
Should Emacs use the GNU version of malloc? no
(The GNU allocators don't work with this system configuration.)
Should Emacs use a relocating allocator for buffers? no
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? nextstep
What toolkit should Emacs use? none
Where do we find X Windows header files? NONE
Where do we find X Windows libraries? NONE
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? no
Does Emacs use -ljpeg? yes
Does Emacs use -ltiff? yes
Does Emacs use a gif library? yes -lgif
Does Emacs use a png library? yes -L/usr/local/Cellar/libpng/1.6.37/lib -lpng16 -lz
Does Emacs use -lrsvg-2? no
Does Emacs use -lwebp? yes
Does Emacs use -lsqlite3? yes
Does Emacs use cairo? no
Does Emacs use -llcms2? yes
Does Emacs use imagemagick? no
Does Emacs use native APIs for images? yes (ns)
Does Emacs support sound? no
Does Emacs use -lgpm? no
Does Emacs use -ldbus? no
Does Emacs use -lgconf? no
Does Emacs use GSettings? no
Does Emacs use a file notification library? yes (kqueue)
Does Emacs use access control lists? yes
Does Emacs use -lselinux? no
Does Emacs use -lgnutls? yes
Does Emacs use -lxml2? yes
Does Emacs use -lfreetype? no
Does Emacs use HarfBuzz? no
Does Emacs use -lm17n-flt? no
Does Emacs use -lotf? no
Does Emacs use -lxft? no
Does Emacs use -lsystemd? no
Does Emacs use -ljansson? yes
Does Emacs use the GMP library? yes
Does Emacs directly use zlib? yes
Does Emacs have dynamic modules support? yes
Does Emacs use toolkit scroll bars? yes
Does Emacs support Xwidgets? no
Does Emacs have threading support in lisp? yes
Does Emacs support the portable dumper? yes
Does Emacs support legacy unexec dumping? no
Which dumping strategy does Emacs use? pdumper
Does Emacs have native lisp compiler? no
Does Emacs use version 2 of the X Input Extension? no
Does Emacs generate a smaller-size Japanese dictionary? no
--8<---------------cut here---------------end--------------->8---
and `make' which printed, inter alia,
--8<---------------cut here---------------start------------->8---
CCLD temacs
ld: warning: dylib (/usr/local/lib/libtiff.dylib) was built for newer macOS version (12.0) than being linked (11.1)
ld: warning: dylib (/usr/local/lib/libjpeg.dylib) was built for newer macOS version (12.0) than being linked (11.1)
ld: warning: dylib (/usr/local/Cellar/webp/1.2.4/lib/libwebpdemux.dylib) was built for newer macOS version (12.0) than being linked (11.1)
ld: warning: dylib (/usr/local/Cellar/webp/1.2.4/lib/libwebp.dylib) was built for newer macOS version (12.0) than being linked (11.1)
ld: warning: dylib (/usr/local/Cellar/gnutls/3.7.7/lib/libgnutls.dylib) was built for newer macOS version (12.0) than being linked (11.1)
ld: warning: dylib (/usr/local/Cellar/little-cms2/2.13.1_1/lib/liblcms2.dylib) was built for newer macOS version (12.0) than being linked (11.1)
--8<---------------cut here---------------end--------------->8---
> You then run that Emacs in LLDB
>
> cd src
> lldb emacs
--8<---------------cut here---------------start------------->8---
lldb) run
Process 18589 launched: '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64)
emacs(18589,0x101748600) malloc: nano zone abandoned due to inability to preallocate reserved vm space.
2022-09-13 10:48:24.884165-0400 emacs[18589:5791720] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=18589
2022-09-13 10:48:24.884326-0400 emacs[18589:5791720] SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
2022-09-13 10:48:25.535780-0400 emacs[18589:5791720] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=18589
2022-09-13 10:48:25.535931-0400 emacs[18589:5791720] SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
2022-09-13 10:48:26.251257-0400 emacs[18589:5791720] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=18589
2022-09-13 10:48:26.251426-0400 emacs[18589:5791720] SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
2022-09-13 10:48:26.252541-0400 emacs[18589:5791720] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=18589
2022-09-13 10:48:26.252654-0400 emacs[18589:5791720] SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
2022-09-13 10:48:30.932717-0400 emacs[18589:5791720] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=18589
2022-09-13 10:48:30.932872-0400 emacs[18589:5791720] SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
2022-09-13 10:48:30.934031-0400 emacs[18589:5791720] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=18589
2022-09-13 10:48:30.934108-0400 emacs[18589:5791720] SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
Process 18589 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ff8c11d6f70)
frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d6f70) at alloc.c:4020:14
4017 {
4018 return pdumper_object_p (s)
4019 ? pdumper_marked_p (s)
-> 4020 : s->u.s.gcmarkbit;
4021 }
4022
4023 static void
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ff8c11d6f70)
* frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d6f70) at alloc.c:4020:14
frame #1: 0x00000001006db869 emacs`process_mark_stack(base_sp=0) at alloc.c:6943:10
frame #2: 0x00000001006d9a79 emacs`mark_object(obj=0x00007ff7bfee99d0) at alloc.c:7035:3
frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
frame #4: 0x00000001006d7adc emacs`garbage_collect at alloc.c:6187:3
frame #5: 0x00000001006d70b6 emacs`maybe_garbage_collect at alloc.c:6090:5
frame #6: 0x00000001008a6939 emacs`maybe_gc at lisp.h:5564:5
frame #7: 0x0000000100892632 emacs`exec_byte_code(fun=0x0000621001903355, args_template=257, nargs=1, args=0x000000010d0023e8) at bytecode.c:782:6
frame #8: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x0000621001946b15, args_template=257, nargs=1, args=0x000000010d001da8) at eval.c:3101:10
frame #9: 0x0000000100790587 emacs`funcall_lambda(fun=0x0000621001946b15, nargs=1, arg_vector=0x000000010d001da8) at eval.c:3173:9
frame #10: 0x000000010078e703 emacs`funcall_general(fun=0x0000621001946b15, numargs=1, args=0x000000010d001da8) at eval.c:2964:12
frame #11: 0x000000010077af9b emacs`Ffuncall(nargs=2, args=0x000000010d001da0) at eval.c:3014:21
frame #12: 0x0000000100785ea5 emacs`Fapply(nargs=2, args=0x000000010d001da0) at eval.c:2642:14
frame #13: 0x000000010078ff1c emacs`funcall_subr(subr=0x0000000100cc3ca0, numargs=2, args=0x000000010d001da0) at eval.c:3079:9
frame #14: 0x00000001008928de emacs`exec_byte_code(fun=0x00006210018eb7a5, args_template=385, nargs=2, args=0x000000010d001d10) at bytecode.c:809:14
frame #15: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00006210018eb7a5, args_template=385, nargs=2, args=0x000000010d001d08) at eval.c:3101:10
frame #16: 0x0000000100790587 emacs`funcall_lambda(fun=0x00006210018eb7a5, nargs=2, arg_vector=0x000000010d001d08) at eval.c:3173:9
frame #17: 0x000000010078e703 emacs`funcall_general(fun=0x00006210018eb7a5, numargs=2, args=0x000000010d001d08) at eval.c:2964:12
frame #18: 0x000000010077af9b emacs`Ffuncall(nargs=3, args=0x000000010d001d00) at eval.c:3014:21
frame #19: 0x0000000100785ea5 emacs`Fapply(nargs=3, args=0x000000010d001d00) at eval.c:2642:14
frame #20: 0x000000010078ff1c emacs`funcall_subr(subr=0x0000000100cc3ca0, numargs=3, args=0x000000010d001d00) at eval.c:3079:9
frame #21: 0x00000001008928de emacs`exec_byte_code(fun=0x0000621001929fc5, args_template=514, nargs=2, args=0x000000010d001d08) at bytecode.c:809:14
frame #22: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00000001060419d5, args_template=769, nargs=1, args=0x000000010d001b90) at eval.c:3101:10
frame #23: 0x0000000100790587 emacs`funcall_lambda(fun=0x00000001060419d5, nargs=1, arg_vector=0x000000010d001b90) at eval.c:3173:9
frame #24: 0x000000010078e703 emacs`funcall_general(fun=0x00000001060419d5, numargs=1, args=0x000000010d001b90) at eval.c:2964:12
frame #25: 0x000000010077af9b emacs`Ffuncall(nargs=2, args=0x000000010d001b88) at eval.c:3014:21
frame #26: 0x0000000100785ea5 emacs`Fapply(nargs=2, args=0x000000010d001b88) at eval.c:2642:14
frame #27: 0x000000010078ff1c emacs`funcall_subr(subr=0x0000000100cc3ca0, numargs=2, args=0x000000010d001b88) at eval.c:3079:9
frame #28: 0x00000001008928de emacs`exec_byte_code(fun=0x00000001060159ad, args_template=770, nargs=2, args=0x000000010d001be8) at bytecode.c:809:14
frame #29: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00006210018b3575, args_template=256, nargs=0, args=0x000000010d001938) at eval.c:3101:10
frame #30: 0x0000000100790587 emacs`funcall_lambda(fun=0x00006210018b3575, nargs=0, arg_vector=0x000000010d001938) at eval.c:3173:9
frame #31: 0x000000010078e703 emacs`funcall_general(fun=0x00006210018b3575, numargs=0, args=0x000000010d001938) at eval.c:2964:12
frame #32: 0x0000000100892908 emacs`exec_byte_code(fun=0x00000001061fd5a5, args_template=0, nargs=0, args=0x000000010d001930) at bytecode.c:811:14
frame #33: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00000001061bfb75, args_template=0, nargs=0, args=0x00007ff7bfefdac0) at eval.c:3101:10
frame #34: 0x0000000100790587 emacs`funcall_lambda(fun=0x00000001061bfb75, nargs=0, arg_vector=0x00007ff7bfefdac0) at eval.c:3173:9
frame #35: 0x00000001007858e2 emacs`apply_lambda(fun=0x00000001061bfb75, args=0x0000000000000000, count=(bytes = 128)) at eval.c:3123:9
frame #36: 0x0000000100772d3f emacs`eval_sub(form=0x0000000106abe8bb) at eval.c:2564:12
frame #37: 0x0000000100782a67 emacs`Feval(form=0x0000000106abe8bb, lexical=0x0000000000000000) at eval.c:2375:28
frame #38: 0x000000010052c40b emacs`top_level_2 at keyboard.c:1141:10
frame #39: 0x000000010077d829 emacs`internal_condition_case(bfun=(emacs`top_level_2 at keyboard.c:1140), handlers=0x0000000000000090, hfun=(emacs`cmd_error at keyboard.c:935)) at eval.c:1497:25
frame #40: 0x000000010052c300 emacs`top_level_1(ignore=0x0000000000000000) at keyboard.c:1149:5
frame #41: 0x000000010077bb4d emacs`internal_catch(tag=0x000000000000ea00, func=(emacs`top_level_1 at keyboard.c:1146), arg=0x0000000000000000) at eval.c:1220:25
frame #42: 0x00000001004e6984 emacs`command_loop at keyboard.c:1109:2
frame #43: 0x00000001004e6496 emacs`recursive_edit_1 at keyboard.c:719:9
frame #44: 0x00000001004e737f emacs`Frecursive_edit at keyboard.c:802:3
frame #45: 0x00000001004debe6 emacs`main(argc=1, argv=0x00007ff7bfeff220) at emacs.c:2517:3
frame #46: 0x00000001016cd52e dyld`start + 462
--8<---------------cut here---------------end--------------->8---
what do I do next?
Would you like to get on the phone to drive my fingers? ;-)
--
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://fairforall.org http://think-israel.org
To be popular with ladies one has to be smart, handsome & rich. Or to be a cat.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Wed, 14 Sep 2022 05:47:01 GMT) Full text and rfc822 format available.Message #14 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Wed, 14 Sep 2022 07:46:00 +0200
Sam Steingold <sds <at> gnu.org> writes:
>> (If you use it for building Emacs, you'll need to "brew install bear",
>> or remove the call to bear in the script. Also, you might want to use
>> --elc if you don't use native compilatin.)
>
> I think native compilation is disabled on mac by default.
That's correct. I was mentioning --elc only because make-emacs defaults
to configuring --with-native-compilation, because I'm using that 99% of
the time.
> I build my normal Emacs out of the tree, so the source tree is already
> clean, thus I just did
>
> ./autogen.sh
> ./configure LDFLAGS="-fsanitize=address -fno-omit-frame-pointer"
> CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer"
Looks good.
> and `make' which printed, inter alia,
> ld: warning: dylib
> (/usr/local/Cellar/little-cms2/2.13.1_1/lib/liblcms2.dylib) was
> built for newer macOS version (12.0) than being linked (11.1)
AFAIK these warnings are annoying but harmless.
> 2022-09-13 10:48:30.934108-0400 emacs[18589:5791720] SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
> Process 18589 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x7ff8c11d6f70)
That's not so good. It means the address sanitizer couldn't catch
anything before Emacs crashed.
I'm afraid now it's going to get tedious, without some divine
inspiration.
> frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d6f70) at alloc.c:4020:14
> 4017 {
> 4018 return pdumper_object_p (s)
> 4019 ? pdumper_marked_p (s)
> -> 4020 : s->u.s.gcmarkbit;
> 4021 }
> 4022
> 4023 static void
> Target 0: (emacs) stopped.
Hm, it's a fake Lisp symbol this time. Last time it was a fake float.
Which fits the hypothesis of something writing "randomly" to the heap.
Or it could be uninitialized memory, maybe.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x7ff8c11d6f70)
> * frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d6f70) at alloc.c:4020:14
> frame #1: 0x00000001006db869 emacs`process_mark_stack(base_sp=0) at alloc.c:6943:10
> frame #2: 0x00000001006d9a79 emacs`mark_object(obj=0x00007ff7bfee99d0) at alloc.c:7035:3
> frame #3: 0x000000010052bf20 emacs`mark_kboards at
> keyboard.c:13266:4
Last time there was also a mark_kboards on the stack. I wonder if
that tells us something.
> what do I do next?
Good question ;-).
Could you please check the following:
- Does it also crash when you run emacs on a terminal (-nw)? If not, it
could be a hint that the cuöprit is in the NS GUI code.
- Could you please see if it crashes consistently in different runs?
What I mean is that is crashes in the same function with the same
backtrace and the same pointer value of the symbol in frame#0? I
guess I would quit LLDB between between runs, for no good reason
:-), just to make sure it's reproducible that way.
- I think you mentioned that the crashes started not so long ago? Do
you perhaps know a commit which is still "good"? Or maybe a time,
like 4 weeks ago, or so? We would need a good commit for git bisect
anyway.
> Would you like to get on the phone to drive my fingers? ;-)
Hehe, that could only be helpful if I knew what I'm doing :-).
(If I'm trying the be too "helpful", please just tekk ne. I Know that
I'm sometimes doing that. No problem.)
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Wed, 14 Sep 2022 11:31:02 GMT) Full text and rfc822 format available.Message #17 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Wed, 14 Sep 2022 13:30:18 +0200
Sam Steingold <sds <at> gnu.org> writes: > frame #3: 0x000000010052bf20 emacs`mark_kboards at > keyboard.c:13266:4 The contents of the local variable event would be interesting in frame#3 ü *event
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Wed, 14 Sep 2022 11:33:02 GMT) Full text and rfc822 format available.Message #20 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Wed, 14 Sep 2022 13:32:29 +0200
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Sam Steingold <sds <at> gnu.org> writes:
>
>> frame #3: 0x000000010052bf20 emacs`mark_kboards at
>> keyboard.c:13266:4
>
> The contents of the local variable event would be interesting in frame#3
>
> ü *event
Also maybe
p event->ie
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Wed, 14 Sep 2022 18:21:01 GMT) Full text and rfc822 format available.Message #23 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Wed, 14 Sep 2022 14:20:05 -0400
> * Gerd Möllmann <treq.zbryyznaa <at> tznvy.pbz> [2022-09-14 13:30:18 +0200]:
>
> Sam Steingold <sds <at> gnu.org> writes:
>
>> frame #3: 0x000000010052bf20 emacs`mark_kboards at
>> keyboard.c:13266:4
>
> The contents of the local variable event would be interesting in frame#3
>
> ü *event
--8<---------------cut here---------------start------------->8---
(lldb)
frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
13263 mark_object (event->ie.x);
13264 mark_object (event->ie.y);
13265 mark_object (event->ie.frame_or_window);
-> 13266 mark_object (event->ie.arg);
13267
13268 /* This should never be allocated for a single event, but
13269 mark it anyway in the situation where the list of devices
(lldb) p event
warning: could not find Objective-C class data in the process. This may reduce the quality of type information available.
(buffered_input_event *) $0 = 0x0000000101295c80
(lldb) p *event
(buffered_input_event) $1 = {
kind = MOVE_FRAME_EVENT
ie = {
kind = MOVE_FRAME_EVENT
part = scroll_bar_nowhere
code = 0
modifiers = 49116832
x = 0xfffffffffffff85e
y = 0xffffffffffffe9e6
timestamp = 105759277384896
frame_or_window = 0x00006210000d9135
arg = 0x00007ff7bfee99d0
device = 0x00000001021dabaa
}
}
(lldb) p event->ie.arg
(Lisp_Object) $2 = 0x00007ff7bfee99d0
(lldb) p *event->ie.arg
error: error: incomplete type 'Lisp_X' where a complete type is required
note: forward declaration of 'Lisp_X'
--8<---------------cut here---------------end--------------->8---
indeed the crash very often happens when I move the frame (Emacs fails
to place and size itself properly on startup, so this is the first thing
I have to do. I keep Emacs maximized - but _not_ full screen).
Another thing is that Tramp appears to be broken recently - it keeps
timing out even though I can ssh to the remove host without any problems.
--
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://iris.org.il https://www.dhimmitude.org https://fairforall.org
The Truth does not have to look plausible.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Wed, 14 Sep 2022 18:37:02 GMT) Full text and rfc822 format available.Message #26 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Wed, 14 Sep 2022 14:36:30 -0400
> * Gerd Möllmann <treq.zbryyznaa <at> tznvy.pbz> [2022-09-14 07:46:00 +0200]:
>
> Sam Steingold <sds <at> gnu.org> writes:
>
>> 2022-09-13 10:48:30.934108-0400 emacs[18589:5791720] SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
>> Process 18589 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason =
>> EXC_BAD_ACCESS (code=1, address=0x7ff8c11d6f70)
>
> That's not so good. It means the address sanitizer couldn't catch
> anything before Emacs crashed.
>
>> frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d6f70) at alloc.c:4020:14
>> 4017 {
>> 4018 return pdumper_object_p (s)
>> 4019 ? pdumper_marked_p (s)
>> -> 4020 : s->u.s.gcmarkbit;
>> 4021 }
>> 4022
>> 4023 static void
>> Target 0: (emacs) stopped.
>
> Hm, it's a fake Lisp symbol this time. Last time it was a fake float.
> Which fits the hypothesis of something writing "randomly" to the heap.
>
> Or it could be uninitialized memory, maybe.
I _think_ that Tramp does something with a BAD FD and corrupts the
memory (see my previous message: tramp appears to be broken recently).
> - Does it also crash when you run emacs on a terminal (-nw)? If not, it
> could be a hint that the cuöprit is in the NS GUI code.
--8<---------------cut here---------------start------------->8---
(lldb) run -nw
There is a running process, kill it and restart?: [Y/n] y
Process 18589 exited with status = 9 (0x00000009)
Process 53208 launched: '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64)
emacs(53208,0x101748600) malloc: nano zone abandoned due to inability to preallocate reserved vm space.
Process 53208 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTTOU
frame #0: 0x00007ff81575bec6 libsystem_kernel.dylib`__ioctl + 10
libsystem_kernel.dylib`__ioctl:
-> 0x7ff81575bec6 <+10>: jae 0x7ff81575bed0 ; <+20>
0x7ff81575bec8 <+12>: movq %rax, %rdi
0x7ff81575becb <+15>: jmp 0x7ff815759db9 ; cerror
0x7ff81575bed0 <+20>: retq
Target 0: (emacs) stopped.
--8<---------------cut here---------------end--------------->8---
> - Could you please see if it crashes consistently in different runs?
> What I mean is that is crashes in the same function with the same
> backtrace and the same pointer value of the symbol in frame#0? I
> guess I would quit LLDB between between runs, for no good reason
> :-), just to make sure it's reproducible that way.
I restarted lldb and run Emacs.
This time I let it finish restoring desktop _completely_ before moving
the frame - it did __NOT__ crash. I moved the frame around, no crash.
Then I quit it and restarted and moved the frame while it was in the
process of re-creating *vc-dir* buffers.
--8<---------------cut here---------------start------------->8---
(lldb) run
Process 53726 launched: '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64)
emacs(53726,0x101748600) malloc: nano zone abandoned due to inability to preallocate reserved vm space.
2022-09-14 14:30:05.960741-0400 emacs[53726:6357538] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=53726
2022-09-14 14:30:05.960890-0400 emacs[53726:6357538] SecTaskCopyDebugDescription: emacs[53726]/0#-1 LF=0
2022-09-14 14:30:06.092509-0400 emacs[53726:6357538] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=53726
2022-09-14 14:30:06.092656-0400 emacs[53726:6357538] SecTaskCopyDebugDescription: emacs[53726]/0#-1 LF=0
2022-09-14 14:30:06.291206-0400 emacs[53726:6357538] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=53726
2022-09-14 14:30:06.291334-0400 emacs[53726:6357538] SecTaskCopyDebugDescription: emacs[53726]/0#-1 LF=0
2022-09-14 14:30:06.292448-0400 emacs[53726:6357538] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=53726
2022-09-14 14:30:06.292534-0400 emacs[53726:6357538] SecTaskCopyDebugDescription: emacs[53726]/0#-1 LF=0
Process 53726 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ff8c11d2f50)
frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d2f50) at alloc.c:4020:14
4017 {
4018 return pdumper_object_p (s)
4019 ? pdumper_marked_p (s)
-> 4020 : s->u.s.gcmarkbit;
4021 }
4022
4023 static void
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ff8c11d2f50)
* frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d2f50) at alloc.c:4020:14
frame #1: 0x00000001006db869 emacs`process_mark_stack(base_sp=0) at alloc.c:6943:10
frame #2: 0x00000001006d9a79 emacs`mark_object(obj=0x00007ff7bfee59b0) at alloc.c:7035:3
frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
frame #4: 0x00000001006d7adc emacs`garbage_collect at alloc.c:6187:3
frame #5: 0x00000001006d70b6 emacs`maybe_garbage_collect at alloc.c:6090:5
frame #6: 0x00000001008a6939 emacs`maybe_gc at lisp.h:5564:5
frame #7: 0x0000000100892632 emacs`exec_byte_code(fun=0x00006210009589b5, args_template=770, nargs=3, args=0x000000010d002000) at bytecode.c:782:6
frame #8: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x000062100038356d, args_template=2953, nargs=11, args=0x00007ff7bfef2040) at eval.c:3101:10
frame #9: 0x0000000100790587 emacs`funcall_lambda(fun=0x000062100038356d, nargs=11, arg_vector=0x00007ff7bfef2040) at eval.c:3173:9
frame #10: 0x00000001007858e2 emacs`apply_lambda(fun=0x000062100038356d, args=0x00006290005dee03, count=(bytes = 1216)) at eval.c:3123:9
frame #11: 0x0000000100772d3f emacs`eval_sub(form=0x00006290005dedf3) at eval.c:2564:12
frame #12: 0x00000001008512f3 emacs`readevalloop_eager_expand_eval(val=0x00006290005dedf3, macroexpand=0x0000000005208950) at lread.c:2154:13
frame #13: 0x00000001008396e5 emacs`readevalloop(readcharfun=0x0000621000952dd5, infile0=0x0000000000000000, sourcename=0x0000619002892a04, printflag=false, unibyte=0x0000000000000000, readfun=0x0000000000000000, start=0x0000000000000000, end=0x0000000000000000) at lread.c:2337:15
frame #14: 0x000000010083af03 emacs`Feval_buffer(buffer=0x0000621000952dd5, printflag=0x0000000000000000, filename=0x0000619002892a04, unibyte=0x0000000000000000, do_allow_print=0x0000000000000030) at lread.c:2410:3
frame #15: 0x000000010078f5c2 emacs`funcall_subr(subr=0x0000000100cc8320, numargs=5, args=0x000000010d001a70) at eval.c:3060:15
frame #16: 0x00000001008928de emacs`exec_byte_code(fun=0x0000000106018325, args_template=257, nargs=1, args=0x000000010d001a78) at bytecode.c:809:14
frame #17: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00000001061fae75, args_template=1282, nargs=4, args=0x00007ff7bfef6608) at eval.c:3101:10
frame #18: 0x0000000100790587 emacs`funcall_lambda(fun=0x00000001061fae75, nargs=4, arg_vector=0x00007ff7bfef6608) at eval.c:3173:9
frame #19: 0x000000010078e703 emacs`funcall_general(fun=0x00000001061fae75, numargs=4, args=0x00007ff7bfef6608) at eval.c:2964:12
frame #20: 0x000000010077af9b emacs`Ffuncall(nargs=5, args=0x00007ff7bfef6600) at eval.c:3014:21
frame #21: 0x00000001008365e2 emacs`call4(fn=0x0000000004f0d8a0, arg1=0x0000619002892a04, arg2=0x0000619002892a04, arg3=0x0000000000000030, arg4=0x0000000000000030) at lisp.h:3261:10
frame #22: 0x0000000100830809 emacs`Fload(file=0x000061900282ef84, noerror=0x0000000000000030, nomessage=0x0000000000000030, nosuffix=0x0000000000000030, must_suffix=0x0000000000000000) at lread.c:1477:10
frame #23: 0x000000010078f5c2 emacs`funcall_subr(subr=0x0000000100cc82c0, numargs=4, args=0x000000010d0019a0) at eval.c:3060:15
frame #24: 0x00000001008928de emacs`exec_byte_code(fun=0x00006210000fabb5, args_template=256, nargs=0, args=0x000000010d0019a8) at bytecode.c:809:14
frame #25: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00006210003ab0dd, args_template=0, nargs=0, args=0x00007ff7bfefa728) at eval.c:3101:10
frame #26: 0x0000000100790587 emacs`funcall_lambda(fun=0x00006210003ab0dd, nargs=0, arg_vector=0x00007ff7bfefa728) at eval.c:3173:9
frame #27: 0x000000010078e703 emacs`funcall_general(fun=0x00006210003ab0dd, numargs=0, args=0x00007ff7bfefa728) at eval.c:2964:12
frame #28: 0x000000010077af9b emacs`Ffuncall(nargs=1, args=0x00007ff7bfefa720) at eval.c:3014:21
frame #29: 0x000000010078dc4d emacs`funcall_nil(nargs=1, args=0x00007ff7bfefa720) at eval.c:2696:3
frame #30: 0x000000010078dba8 emacs`run_hook_with_args(nargs=1, args=0x00007ff7bfefa720, funcall=(emacs`funcall_nil at eval.c:2695)) at eval.c:2873:14
frame #31: 0x000000010078d5b4 emacs`Frun_hook_with_args(nargs=1, args=0x00007ff7bfefa720) at eval.c:2738:10
frame #32: 0x000000010078d524 emacs`run_hook(hook=0x00006210003ab0dd) at eval.c:2886:3
frame #33: 0x000000010078d3fd emacs`Frun_hooks(nargs=2, args=0x000000010d0018a8) at eval.c:2720:5
frame #34: 0x000000010078ff1c emacs`funcall_subr(subr=0x0000000100cc3dc0, numargs=2, args=0x000000010d0018a8) at eval.c:3079:9
frame #35: 0x00000001008928de emacs`exec_byte_code(fun=0x00000001061fdb8d, args_template=512, nargs=2, args=0x000000010d001940) at bytecode.c:809:14
frame #36: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00000001061bfb75, args_template=0, nargs=0, args=0x00007ff7bfefdac0) at eval.c:3101:10
frame #37: 0x0000000100790587 emacs`funcall_lambda(fun=0x00000001061bfb75, nargs=0, arg_vector=0x00007ff7bfefdac0) at eval.c:3173:9
frame #38: 0x00000001007858e2 emacs`apply_lambda(fun=0x00000001061bfb75, args=0x0000000000000000, count=(bytes = 128)) at eval.c:3123:9
frame #39: 0x0000000100772d3f emacs`eval_sub(form=0x0000000106abe8bb) at eval.c:2564:12
frame #40: 0x0000000100782a67 emacs`Feval(form=0x0000000106abe8bb, lexical=0x0000000000000000) at eval.c:2375:28
frame #41: 0x000000010052c40b emacs`top_level_2 at keyboard.c:1141:10
frame #42: 0x000000010077d829 emacs`internal_condition_case(bfun=(emacs`top_level_2 at keyboard.c:1140), handlers=0x0000000000000090, hfun=(emacs`cmd_error at keyboard.c:935)) at eval.c:1497:25
frame #43: 0x000000010052c300 emacs`top_level_1(ignore=0x0000000000000000) at keyboard.c:1149:5
frame #44: 0x000000010077bb4d emacs`internal_catch(tag=0x000000000000ea00, func=(emacs`top_level_1 at keyboard.c:1146), arg=0x0000000000000000) at eval.c:1220:25
frame #45: 0x00000001004e6984 emacs`command_loop at keyboard.c:1109:2
frame #46: 0x00000001004e6496 emacs`recursive_edit_1 at keyboard.c:719:9
frame #47: 0x00000001004e737f emacs`Frecursive_edit at keyboard.c:802:3
frame #48: 0x00000001004debe6 emacs`main(argc=1, argv=0x00007ff7bfeff220) at emacs.c:2517:3
frame #49: 0x00000001016cd52e dyld`start + 462
(lldb) f 3
frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
13263 mark_object (event->ie.x);
13264 mark_object (event->ie.y);
13265 mark_object (event->ie.frame_or_window);
-> 13266 mark_object (event->ie.arg);
13267
13268 /* This should never be allocated for a single event, but
13269 mark it anyway in the situation where the list of devices
(lldb) p *event
(buffered_input_event) $0 = {
kind = MOVE_FRAME_EVENT
ie = {
kind = MOVE_FRAME_EVENT
part = scroll_bar_nowhere
code = 0
modifiers = 801101
x = 0x00000000000006ea
y = 0xfffffffffffff78a
timestamp = 0
frame_or_window = 0x00006210000d9135
arg = 0x00007ff7bfee59b0
device = 0x0000000102211ff0
}
}
(lldb)
--8<---------------cut here---------------end--------------->8---
looks consistent with the previous crash.
> - I think you mentioned that the crashes started not so long ago? Do
> you perhaps know a commit which is still "good"? Or maybe a time,
> like 4 weeks ago, or so? We would need a good commit for git bisect
> anyway.
I am "pretty sure" that 2 weeks ago it was good.
> (If I'm trying the be too "helpful", please just tekk ne. I Know that
> I'm sometimes doing that. No problem.)
You are very helpful, and I appreciate your attention!
Thank you very much!
--
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://www.dhimmitude.org https://thereligionofpeace.com https://camera.org
A slave dreams not of Freedom, but of owning his own slaves.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 04:50:02 GMT) Full text and rfc822 format available.Message #29 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 06:49:31 +0200
Sam Steingold <sds <at> gnu.org> writes:
> (lldb)
> frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
> 13263 mark_object (event->ie.x);
> 13264 mark_object (event->ie.y);
> 13265 mark_object (event->ie.frame_or_window);
> -> 13266 mark_object (event->ie.arg);
> 13267
> 13268 /* This should never be allocated for a single event, but
> 13269 mark it anyway in the situation where the list of devices
> (lldb) p event
> warning: could not find Objective-C class data in the process. This may reduce the quality of type information available.
> (buffered_input_event *) $0 = 0x0000000101295c80
> (lldb) p *event
> (buffered_input_event) $1 = {
> kind = MOVE_FRAME_EVENT
> ie = {
> kind = MOVE_FRAME_EVENT
> part = scroll_bar_nowhere
> code = 0
> modifiers = 49116832
> x = 0xfffffffffffff85e
> y = 0xffffffffffffe9e6
> timestamp = 105759277384896
> frame_or_window = 0x00006210000d9135
> arg = 0x00007ff7bfee99d0
> device = 0x00000001021dabaa
> }
Ok, whatever scroll_bar_nowhere is...
> }
> (lldb) p event->ie.arg
> (Lisp_Object) $2 = 0x00007ff7bfee99d0
Looks like I guess I forgot to tell something. It's not very important
here, but anyway: The output of 'p' looks a bit different when
emacs_lldb.py has been loaded in LLDB. And it probably hasn't been
loaded because LLDB requires either a --local-lldbinit command line
flags, or a setting in ~/.lldbinit to load the src/.lldbinit. The
comment at the start of src/.lldbinit contains instructions. One can
recognize if emacs_lldb.py has been loaded in LLDB because it prints
something like "I have been loaded" when LLDB is started.
> indeed the crash very often happens when I move the frame (Emacs fails
> to place and size itself properly on startup, so this is the first thing
> I have to do. I keep Emacs maximized - but _not_ full screen).
Ok.
> Another thing is that Tramp appears to be broken recently - it keeps
> timing out even though I can ssh to the remove host without any problems.
You mean this makes startup slower, so that moving the frame manually,
and the crash, don't know, might somehow interfere with/depend on that
delay? Ok, that might be good hint. I'll keep it in mind.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 05:29:01 GMT) Full text and rfc822 format available.Message #32 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 07:28:17 +0200
Sam Steingold <sds <at> gnu.org> writes:
> I _think_ that Tramp does something with a BAD FD and corrupts the
> memory (see my previous message: tramp appears to be broken recently).
Hm. There have been a number of Tramp commits/fixes recently, so it
could be that something broke. I'd report that as a bug, maybe after
updating to the ltest master.
I can't exclude that as a possibility, of course, but I think it's
unlikely that using Tramp can lead to a corruption of the C heap
somehow.
>
>> - Does it also crash when you run emacs on a terminal (-nw)? If not, it
>> could be a hint that the cuöprit is in the NS GUI code.
>
> (lldb) run -nw
> There is a running process, kill it and restart?: [Y/n] y
> Process 18589 exited with status = 9 (0x00000009)
> Process 53208 launched: '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64)
> emacs(53208,0x101748600) malloc: nano zone abandoned due to inability to preallocate reserved vm space.
> Process 53208 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTTOU
> frame #0: 0x00007ff81575bec6 libsystem_kernel.dylib`__ioctl + 10
> libsystem_kernel.dylib`__ioctl:
> -> 0x7ff81575bec6 <+10>: jae 0x7ff81575bed0 ; <+20>
> 0x7ff81575bec8 <+12>: movq %rax, %rdi
> 0x7ff81575becb <+15>: jmp 0x7ff815759db9 ; cerror
> 0x7ff81575bed0 <+20>: retq
> Target 0: (emacs) stopped.
Oh, another thing I forgot to mention: LLDB requires a magic spell for
running terminal apps, instead of "run":
process launch --tty -- -nw
\o/ :-).
>> - Could you please see if it crashes consistently in different runs?
>> What I mean is that is crashes in the same function with the same
>> backtrace and the same pointer value of the symbol in frame#0? I
>> guess I would quit LLDB between between runs, for no good reason
>> :-), just to make sure it's reproducible that way.
>
> I restarted lldb and run Emacs.
> This time I let it finish restoring desktop _completely_ before moving
> the frame - it did __NOT__ crash. I moved the frame around, no crash.
Ok. So we have a workaround, at least.
> Then I quit it and restarted and moved the frame while it was in the
> process of re-creating *vc-dir* buffers.
Ok. Moving means grabbing the titlebar? I'm asking because of the
"part = scroll_bar_nowhere" in the event. I wonder if one has to grab
the frame at a certain location? And, are you using scroll bars or are
they off?
> Process 53726 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ff8c11d2f50)
> frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d2f50) at alloc.c:4020:14
> 4017 {
> 4018 return pdumper_object_p (s)
> 4019 ? pdumper_marked_p (s)
> -> 4020 : s->u.s.gcmarkbit;
> 4021 }
> (lldb) p *event
> (buffered_input_event) $0 = {
> kind = MOVE_FRAME_EVENT
> ie = {
> kind = MOVE_FRAME_EVENT
>
> looks consistent with the previous crash.
That's nice! I feel we're on the trail of the killer. I have no idea
what's behind this, but maybe I can get something that I can reproduce
now.
>
>> - I think you mentioned that the crashes started not so long ago? Do
>> you perhaps know a commit which is still "good"? Or maybe a time,
>> like 4 weeks ago, or so? We would need a good commit for git bisect
>> anyway.
>
> I am "pretty sure" that 2 weeks ago it was good.
Ok.
I think I'll try next to reproduce this desktop loading/moving frame
crash here. When I get something, I'll bisect, and then let's see
further. I'll report back when I have something.
>
>> (If I'm trying the be too "helpful", please just tekk ne. I Know that
>> I'm sometimes doing that. No problem.)
>
> You are very helpful, and I appreciate your attention!
>
> Thank you very much!
Thanks, good to know! Helps.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 08:43:02 GMT) Full text and rfc822 format available.Message #35 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 10:42:12 +0200
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> I think I'll try next to reproduce this desktop loading/moving frame
> crash here. When I get something, I'll bisect, and then let's see
> further. I'll report back when I have something.
Just want to drop this here, because I'll probably only continue
tomorrow. And because I find this a little bit baffling.
Save the following 2 lines as crash.el, which are what I could reduce my
init file to:
(custom-set-variables
'(save-place-mode t))
Then start Emacs from the src directory like this:
lldb emacs
run -Q -l crash.el xdisp.c dispextern.h lisp.h nsterm.m xterm.c
When the Emacs GUI window appears, quickly grab its titlebar with the
mouse and drag it up. I usually need a few trials (< 10) to be
quick enough, or what the reason might be.
Result:
Process 94346 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1705bfbb0)
frame #0: 0x0000000100145e18 emacs`process_mark_stack [inlined] symbol_marked_p(s=0x00000001705bfbb0) at alloc.c:4020:7 [opt]
4017 {
4018 return pdumper_object_p (s)
4019 ? pdumper_marked_p (s)
-> 4020 : s->u.s.gcmarkbit;
4021 }
4022
4023 static void
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1705bfbb0)
* frame #0: 0x0000000100145e18 emacs`process_mark_stack [inlined] symbol_marked_p(s=0x00000001705bfbb0) at alloc.c:4020:7 [opt]
frame #1: 0x0000000100145e08 emacs`process_mark_stack(base_sp=<unavailable>) at alloc.c:6943:10 [opt]
frame #2: 0x0000000100145654 emacs`mark_object(obj=<unavailable>) at alloc.c:7035:3 [opt] [artificial]
frame #3: 0x00000001000f3f44 emacs`mark_kboards at keyboard.c:13266:4 [opt]
frame #4: 0x0000000100144cbc emacs`garbage_collect at alloc.c:6187:3 [opt]
That's the same crash as Sam reported.
Sam, are you also using save-place? Can you reproduce this recipe?
(In case it matters, my places file has 180 lines, and contains entries
for the files I'm loading.)
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 08:49:01 GMT) Full text and rfc822 format available.Message #38 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 10:48:07 +0200
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > Sam, are you also using save-place? Can you reproduce this recipe? It would of course also be interesting if anyone else can reproduce this, maybe even on platforms != macOS.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 09:24:01 GMT) Full text and rfc822 format available.Message #41 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: sds <at> gnu.org, 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 12:23:15 +0300
> Cc: 57751 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Thu, 15 Sep 2022 10:42:12 +0200
>
> Save the following 2 lines as crash.el, which are what I could reduce my
> init file to:
>
> (custom-set-variables
> '(save-place-mode t))
>
> Then start Emacs from the src directory like this:
>
> lldb emacs
> run -Q -l crash.el xdisp.c dispextern.h lisp.h nsterm.m xterm.c
>
> When the Emacs GUI window appears, quickly grab its titlebar with the
> mouse and drag it up. I usually need a few trials (< 10) to be
> quick enough, or what the reason might be.
>
> Result:
>
> Process 94346 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1705bfbb0)
> frame #0: 0x0000000100145e18 emacs`process_mark_stack [inlined] symbol_marked_p(s=0x00000001705bfbb0) at alloc.c:4020:7 [opt]
> 4017 {
> 4018 return pdumper_object_p (s)
> 4019 ? pdumper_marked_p (s)
> -> 4020 : s->u.s.gcmarkbit;
> 4021 }
> 4022
> 4023 static void
I cannot reproduce this. Maybe this is specific to macOS, or maybe
one needs to build with native-comp and/or with optimizations?
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 09:38:02 GMT) Full text and rfc822 format available.Message #44 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: sds <at> gnu.org, 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 11:37:07 +0200
Eli Zaretskii <eliz <at> gnu.org> writes: > I cannot reproduce this. Maybe this is specific to macOS, or maybe > one needs to build with native-comp and/or with optimizations? Thanks. Then it's probably maOS, because Sam isn't using native-comp.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 10:02:01 GMT) Full text and rfc822 format available.Message #47 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 12:01:29 +0200
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > >> Sam, are you also using save-place? Can you reproduce this recipe? > > It would of course also be interesting if anyone else can reproduce > this, maybe even on platforms != macOS. Small update, because I thought it ridiculous that save-place is involved: The crash can be reproduced with ./emacs -Q -eval "(setq enable-local-variables nil)" *.c *.h in src, and dragging the titlebar while Emacs is busy.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 12:11:01 GMT) Full text and rfc822 format available.Message #50 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: sds <at> gnu.org, 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 15:10:00 +0300
> Cc: 57751 <at> debbugs.gnu.org > From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Date: Thu, 15 Sep 2022 12:01:29 +0200 > > The crash can be reproduced with > > ./emacs -Q -eval "(setq enable-local-variables nil)" *.c *.h > > in src, and dragging the titlebar while Emacs is busy. Doesn't happen here.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 15:13:02 GMT) Full text and rfc822 format available.Message #53 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: sds <at> gnu.org, 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 17:12:33 +0200
Thanks. > Am 15.09.2022 um 14:10 schrieb Eli Zaretskii <eliz <at> gnu.org>: > > >> >> Cc: 57751 <at> debbugs.gnu.org >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> >> Date: Thu, 15 Sep 2022 12:01:29 +0200 >> >> The crash can be reproduced with >> >> ./emacs -Q -eval "(setq enable-local-variables nil)" *.c *.h >> >> in src, and dragging the titlebar while Emacs is busy. > > Doesn't happen here.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 16:36:02 GMT) Full text and rfc822 format available.Message #56 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 12:35:40 -0400
> * Gerd Möllmann <treq.zbryyznaa <at> tznvy.pbz> [2022-09-15 07:28:17 +0200]: > > Sam Steingold <sds <at> gnu.org> writes: > >> I _think_ that Tramp does something with a BAD FD and corrupts the >> memory (see my previous message: tramp appears to be broken recently). > > I can't exclude that as a possibility, of course, but I think it's > unlikely that using Tramp can lead to a corruption of the C heap > somehow. I don't think Tramp itself if the culprit, but the underlying networking code. > Oh, another thing I forgot to mention: LLDB requires a magic spell for > running terminal apps, instead of "run": > > process launch --tty -- -nw thank you! > Moving means grabbing the titlebar? yep. > I'm asking because of the "part = scroll_bar_nowhere" in the event. No idea what this is. > And, are you using scroll bars or are they off? they are present on the screen but I never click on them, I merely use them as a visual indicator of buffer position. > I think I'll try next to reproduce this desktop loading/moving frame > crash here. When I get something, I'll bisect, and then let's see > further. I'll report back when I have something. Thank you! -- Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113 https://lastingimpactpsychology.com https://steingoldpsychology.com https://iris.org.il https://jihadwatch.org http://think-israel.org Brain is invisible, but lack thereof is not.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 16:46:02 GMT) Full text and rfc822 format available.Message #59 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 12:45:30 -0400
> * Gerd Möllmann <treq.zbryyznaa <at> tznvy.pbz> [2022-09-15 10:42:12 +0200]:
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> Sam, are you also using save-place?
nope.
> Can you reproduce this recipe?
yes:
--8<---------------cut here---------------start------------->8---
$ lldb --local-lldbinit emacs
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: bad operand type for unary -: 'NoneType'
Emacs debugging support has been installed.
(lldb) target create "emacs"
Current executable set to '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64).
(lldb) run -Q -l ~/crash.el xdisp.c dispextern.h lisp.h nsterm.m xterm.c
Process 71211 launched: '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64)
emacs(71211,0x101748600) malloc: nano zone abandoned due to inability to preallocate reserved vm space.
2022-09-15 12:41:35.485362-0400 emacs[71211:6607489] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=71211
2022-09-15 12:41:35.485676-0400 emacs[71211:6607489] SecTaskCopyDebugDescription: emacs[71211]/0#-1 LF=0
2022-09-15 12:41:35.621520-0400 emacs[71211:6607489] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=71211
2022-09-15 12:41:35.621660-0400 emacs[71211:6607489] SecTaskCopyDebugDescription: emacs[71211]/0#-1 LF=0
2022-09-15 12:41:36.369148-0400 emacs[71211:6607489] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=71211
2022-09-15 12:41:36.369287-0400 emacs[71211:6607489] SecTaskCopyDebugDescription: emacs[71211]/0#-1 LF=0
2022-09-15 12:41:36.370415-0400 emacs[71211:6607489] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=71211
2022-09-15 12:41:36.370514-0400 emacs[71211:6607489] SecTaskCopyDebugDescription: emacs[71211]/0#-1 LF=0
2022-09-15 12:41:36.504341-0400 emacs[71211:6607489] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=71211
2022-09-15 12:41:36.504442-0400 emacs[71211:6607489] SecTaskCopyDebugDescription: emacs[71211]/0#-1 LF=0
Process 71211 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ff8c11e4550)
frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11e4550) at alloc.c:4020:14
4017 {
4018 return pdumper_object_p (s)
4019 ? pdumper_marked_p (s)
-> 4020 : s->u.s.gcmarkbit;
4021 }
4022
4023 static void
Target 0: (emacs) stopped.
(lldb) bt
warning: could not find Objective-C class data in the process. This may reduce the quality of type information available.
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ff8c11e4550)
* frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11e4550) at alloc.c:4020:14
frame #1: 0x00000001006db869 emacs`process_mark_stack(base_sp=0) at alloc.c:6943:10
frame #2: 0x00000001006d9a79 emacs`mark_object(obj=0x00007ff7bfef6fb0) at alloc.c:7035:3
frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
frame #4: 0x00000001006d7adc emacs`garbage_collect at alloc.c:6187:3
frame #5: 0x00000001006d70b6 emacs`maybe_garbage_collect at alloc.c:6090:5
frame #6: 0x00000001008a6939 emacs`maybe_gc at lisp.h:5564:5
frame #7: 0x0000000100892632 emacs`exec_byte_code(fun=0x0000621000372085, args_template=514, nargs=2, args=0x000000010d002048) at bytecode.c:782:6
frame #8: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00006210004657cd, args_template=257, nargs=1, args=0x00007ff7bfef75c8) at eval.c:3101:10
frame #9: 0x0000000100790587 emacs`funcall_lambda(fun=0x00006210004657cd, nargs=1, arg_vector=0x00007ff7bfef75c8) at eval.c:3173:9
frame #10: 0x000000010078e703 emacs`funcall_general(fun=0x00006210004657cd, numargs=1, args=0x00007ff7bfef75c8) at eval.c:2964:12
frame #11: 0x000000010077af9b emacs`Ffuncall(nargs=2, args=0x00007ff7bfef75c0) at eval.c:3014:21
frame #12: 0x00000001007c082e emacs`call1(fn=0x00006210004657cd, arg1=0x0000618f012679a0) at lisp.h:3239:10
frame #13: 0x00000001007bce34 emacs`mapcar1(leni=8, vals=0x0000000000000000, fn=0x00006210004657cd, seq=0x00006290000fbb33) at fns.c:2867:24
frame #14: 0x00000001007bed88 emacs`Fmapc(function=0x00006210004657cd, sequence=0x00006290000fbb33) at fns.c:2982:3
frame #15: 0x000000010078f092 emacs`funcall_subr(subr=0x0000000100cc6a60, numargs=2, args=0x000000010d001f70) at eval.c:3054:15
frame #16: 0x00000001008928de emacs`exec_byte_code(fun=0x000000010601321d, args_template=1026, nargs=4, args=0x000000010d001fc8) at bytecode.c:809:14
frame #17: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00006210007386b5, args_template=0, nargs=0, args=0x000000010d001d60) at eval.c:3101:10
frame #18: 0x0000000100790587 emacs`funcall_lambda(fun=0x00006210007386b5, nargs=0, arg_vector=0x000000010d001d60) at eval.c:3173:9
frame #19: 0x000000010078e703 emacs`funcall_general(fun=0x00006210007386b5, numargs=0, args=0x000000010d001d60) at eval.c:2964:12
frame #20: 0x0000000100892908 emacs`exec_byte_code(fun=0x000000010617c00d, args_template=513, nargs=2, args=0x000000010d001d20) at bytecode.c:811:14
frame #21: 0x00000001007980e7 emacs`fetch_and_exec_byte_code(fun=0x00000001061bfb75, args_template=0, nargs=0, args=0x00007ff7bfefda60) at eval.c:3101:10
frame #22: 0x0000000100790587 emacs`funcall_lambda(fun=0x00000001061bfb75, nargs=0, arg_vector=0x00007ff7bfefda60) at eval.c:3173:9
frame #23: 0x00000001007858e2 emacs`apply_lambda(fun=0x00000001061bfb75, args=0x0000000000000000, count=(bytes = 128)) at eval.c:3123:9
frame #24: 0x0000000100772d3f emacs`eval_sub(form=0x0000000106abe8bb) at eval.c:2564:12
frame #25: 0x0000000100782a67 emacs`Feval(form=0x0000000106abe8bb, lexical=0x0000000000000000) at eval.c:2375:28
frame #26: 0x000000010052c40b emacs`top_level_2 at keyboard.c:1141:10
frame #27: 0x000000010077d829 emacs`internal_condition_case(bfun=(emacs`top_level_2 at keyboard.c:1140), handlers=0x0000000000000090, hfun=(emacs`cmd_error at keyboard.c:935)) at eval.c:1497:25
frame #28: 0x000000010052c300 emacs`top_level_1(ignore=0x0000000000000000) at keyboard.c:1149:5
frame #29: 0x000000010077bb4d emacs`internal_catch(tag=0x000000000000ea00, func=(emacs`top_level_1 at keyboard.c:1146), arg=0x0000000000000000) at eval.c:1220:25
frame #30: 0x00000001004e6984 emacs`command_loop at keyboard.c:1109:2
frame #31: 0x00000001004e6496 emacs`recursive_edit_1 at keyboard.c:719:9
frame #32: 0x00000001004e737f emacs`Frecursive_edit at keyboard.c:802:3
frame #33: 0x00000001004debe6 emacs`main(argc=9, argv=0x00007ff7bfeff1a8) at emacs.c:2517:3
frame #34: 0x00000001016cd52e dyld`start + 462
(lldb) f 3
frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
13263 mark_object (event->ie.x);
13264 mark_object (event->ie.y);
13265 mark_object (event->ie.frame_or_window);
-> 13266 mark_object (event->ie.arg);
13267
13268 /* This should never be allocated for a single event, but
13269 mark it anyway in the situation where the list of devices
(lldb) p *event
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
Traceback (most recent call last):
File "../etc/emacs_lldb.py", line 207, in type_summary_Lisp_Object
return Lisp_Object(obj).summary()
File "../etc/emacs_lldb.py", line 87, in __init__
self.init_lisp_types()
File "../etc/emacs_lldb.py", line 106, in init_lisp_types
self.lisp_type = enumerator_name(t)
File "../etc/emacs_lldb.py", line 36, in enumerator_name
for enum_member in enumerators:
TypeError: 'SBTypeEnumMemberList' object is not iterable
(buffered_input_event) $41 = {
kind = MOVE_FRAME_EVENT
ie = {
kind = MOVE_FRAME_EVENT
part = scroll_bar_nowhere
code = 0
modifiers = 779547
x = 0x0000000000000c2a
y = 0xfffffffffffff7ae
timestamp = 0
frame_or_window = 0x00006210000bb135
arg = 0x00007ff7bfef6fb0
device = 0x0000000102211ff0
}
}
(lldb)
--8<---------------cut here---------------end--------------->8---
--
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
http://think-israel.org https://iris.org.il https://www.dhimmitude.org
non-smoking section in a restaurant == non-peeing section in a swimming pool
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 16:49:02 GMT) Full text and rfc822 format available.Message #62 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 12:48:29 -0400
> * Gerd Möllmann <treq.zbryyznaa <at> tznvy.pbz> [2022-09-15 12:01:29 +0200]: > > Small update, because I thought it ridiculous that save-place is > involved: > > The crash can be reproduced with > > ./emacs -Q -eval "(setq enable-local-variables nil)" *.c *.h > > in src, and dragging the titlebar while Emacs is busy. confirmed! -- Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113 https://lastingimpactpsychology.com https://steingoldpsychology.com https://jij.org https://ffii.org https://mideasttruth.com Feature without an "off" switch is bug.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 22:26:02 GMT) Full text and rfc822 format available.Message #65 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gregory Heytings <gregory <at> heytings.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Sam Steingold <sds <at> gnu.org>, 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 22:25:39 +0000
> > The crash can be reproduced with > > ./emacs -Q -eval "(setq enable-local-variables nil)" *.c *.h > > in src, and dragging the titlebar while Emacs is busy. > I could not reproduce that issue here either (Debian bookworm). Just to be sure, by "dragging the title bar", you mean moving the Emacs frame after clicking on its title bar, right?
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 22:42:02 GMT) Full text and rfc822 format available.Message #68 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: Gregory Heytings <gregory <at> heytings.org> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 18:41:37 -0400
> * Gregory Heytings <tertbel <at> urlgvatf.bet> [2022-09-15 22:25:39 +0000]: > >> >> The crash can be reproduced with >> >> ./emacs -Q -eval "(setq enable-local-variables nil)" *.c *.h >> >> in src, and dragging the titlebar while Emacs is busy. >> > > I could not reproduce that issue here either (Debian bookworm). > Just to be sure, by "dragging the title bar", you mean moving the > Emacs frame after clicking on its title bar, right? yes, while Emacs is busy -- Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113 https://lastingimpactpsychology.com https://steingoldpsychology.com https://thereligionofpeace.com https://jihadwatch.org https://memri.org Lisp: Serious empowerment.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 22:43:01 GMT) Full text and rfc822 format available.Message #71 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: Gregory Heytings <gregory <at> heytings.org> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 18:42:03 -0400
> * Gregory Heytings <tertbel <at> urlgvatf.bet> [2022-09-15 22:25:39 +0000]: > >> >> The crash can be reproduced with >> >> ./emacs -Q -eval "(setq enable-local-variables nil)" *.c *.h >> >> in src, and dragging the titlebar while Emacs is busy. >> > > I could not reproduce that issue here either (Debian bookworm). yes, this is mac-specific > Just to be sure, by "dragging the title bar", you mean moving the > Emacs frame after clicking on its title bar, right? yes, while Emacs is busy -- Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113 https://lastingimpactpsychology.com https://steingoldpsychology.com https://thereligionofpeace.com https://jihadwatch.org https://memri.org Lisp: Serious empowerment.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Thu, 15 Sep 2022 23:18:01 GMT) Full text and rfc822 format available.Message #74 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gregory Heytings <gregory <at> heytings.org> To: Sam Steingold <sds <at> gnu.org> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 23:17:52 +0000
>> I could not reproduce that issue here either (Debian bookworm). > > yes, this is mac-specific > Does it also happen if you turn off the tool bar and the scroll bars? And tooltips, maybe?
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Fri, 16 Sep 2022 05:41:02 GMT) Full text and rfc822 format available.Message #77 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Gregory Heytings <gregory <at> heytings.org> Cc: Sam Steingold <sds <at> gnu.org>, 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Fri, 16 Sep 2022 07:40:07 +0200
Gregory Heytings <gregory <at> heytings.org> writes: >>> I could not reproduce that issue here either (Debian bookworm). >> >> yes, this is mac-specific >> > > Does it also happen if you turn off the tool bar and the scroll bars? > And tooltips, maybe? Should be fixed now. The crash bisected down to 976965eb5ed00ddc8806b2adcbd5761189823f2c from a bit more than a week ago. And the reason for the crash was uninitialized memory, again, aka The Great C Plague. (Which is a lesser problem in C++ because of default contructors, but I didn't want to mention that :-).) What happened is this: The offending commit used an only partly initialized input_event for frame movements on macOS. So every time Emacs was too busy to process input events fast enough, and then a GC happened, the GC would trip over a random value in the movement event. Sam, could you please confirm it's fixed? Also, for the Tramp issue you mentioned, I'd recommend to file a bug, if you didn't already. That sounds like a serious issue to me. Thanks for the support to all, and thanks to Sam for reporing this.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Mon, 19 Sep 2022 16:27:02 GMT) Full text and rfc822 format available.Message #80 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Sam Steingold <sds <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Mon, 19 Sep 2022 12:26:07 -0400
> * Gerd Möllmann <treq.zbryyznaa <at> tznvy.pbz> [2022-09-16 07:40:07 +0200]: > > Sam, could you please confirm it's fixed? Gerd, thank you very much, I no longer observe the bug! > Also, for the Tramp issue you mentioned, I'd recommend to file a bug, > if you didn't already. That sounds like a serious issue to me. I will when I have something bigger than a hunch to report. ;-) -- Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113 https://lastingimpactpsychology.com https://steingoldpsychology.com https://ij.org/ https://ffii.org https://www.dhimmitude.org If you need a helping hand, just remember that you already have two.
bug-gnu-emacs <at> gnu.org:bug#57751; Package emacs.
(Tue, 20 Sep 2022 04:33:01 GMT) Full text and rfc822 format available.Message #83 received at 57751 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Sam Steingold <sds <at> gnu.org> Cc: 57751 <at> debbugs.gnu.org Subject: Re: bug#57751: 29.0.50; crash in GC Date: Tue, 20 Sep 2022 06:32:27 +0200
Sam Steingold <sds <at> gnu.org> writes: >> * Gerd Möllmann <treq.zbryyznaa <at> tznvy.pbz> [2022-09-16 07:40:07 +0200]: >> >> Sam, could you please confirm it's fixed? > > Gerd, thank you very much, I no longer observe the bug! > >> Also, for the Tramp issue you mentioned, I'd recommend to file a bug, >> if you didn't already. That sounds like a serious issue to me. > > I will when I have something bigger than a hunch to report. ;-) Thanks, Sam. Closing.
Gerd Möllmann <gerd.moellmann <at> gmail.com>
to control <at> debbugs.gnu.org.
(Tue, 20 Sep 2022 04:33:02 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Tue, 18 Oct 2022 11:24:10 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.