* bug#57751: 29.0.50; crash in GC @ 2022-09-12 14:37 Sam Steingold 2022-09-13 5:20 ` Gerd Möllmann 0 siblings, 1 reply; 27+ messages in thread From: Sam Steingold @ 2022-09-12 14:37 UTC (permalink / raw) To: 57751 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-12 14:37 bug#57751: 29.0.50; crash in GC Sam Steingold @ 2022-09-13 5:20 ` Gerd Möllmann 2022-09-13 14:51 ` Sam Steingold 0 siblings, 1 reply; 27+ messages in thread From: Gerd Möllmann @ 2022-09-13 5:20 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 [-- Attachment #1: Type: text/plain, Size: 2974 bytes --] Hi Sam, Sam Steingold <sds@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. [-- Attachment #2: make-emacs --] [-- Type: text/plain, Size: 2412 bytes --] #! /usr/bin/env zsh #set -x # Build Emacs from scratch. # Display usage information and exit. function usage () { cat <<EOF Usage $0 [options] Build Emacs starting from a clean Git repository. When run without addtional command-line flags, build with native compilation. --asan build with address sanitizer and -O1 (this takes 3x the time of a build without) --bootstrap make bootstrap --configure run configure only --elc build without native compilation --help show this help --no-cache delete config cache EOF exit 1 } # Parse command line options. zmodload zsh/zutil if ! zparseopts -E -D -F -- \ -asan=asan \ -bootstrap=bootstrap \ -configure=conf \ -elc=elc \ -help=help \ -no-cache=no_cache \ || [ "$help" != "" ] then usage fi # Go to the root of the current worktree. while ! test -f configure.ac; do if [ "$(pwd)" = "/" ]; then echo "Not in worktree" exit fi cd .. done # The file to use as config.cache worktree="$(basename $(pwd))" config_cache=~"/tmp/config.cache.$worktree" # Delete the config cache file if --no-config is specified. if [ "$no_cache" != "" ]; then rm -f $config_cache fi # Flags and options to pass to configure. config_flags=(--cache-file $config_cache) # Build with native compiler unless --elc is specified. if [ "$elc" = "" ]; then config_flags+=(--with-native-compilation) fi # Define CFLAGS and LDFLAGS for address sanitizer if --asan is # specified. if [ "$asan" != "" ]; then config_flags+=(LDFLAGS="-fsanitize=address -fno-omit-frame-pointer" CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer") fi # Clean Git repo, configure and make install. Also, build a # compilation database while we're at it. function build_emacs_from_scratch () { git clean -qxdf \ && ./autogen.sh \ && ./configure $config_flags[@] \ && bear -- make \ && make install } function bootstrap_emacs () { ./configure $config_flags[@] \ && bear -- make bootstrap \ } # Note that the zsh built-in 'time' is not able to time shell # functions directly, it just prints nothing. We have to use a # sub-shell instead. TIMEFMT=$'\nreal\t%*E\nuser\t%*U\nsys\t%*S' if [ "$conf" != "" ]; then time ./configure $config_flags[@] elif [ "$bootstrap" != "" ]; then time (bootstrap_emacs) else time (build_emacs_from_scratch) fi echo "$0 $config_flags[@] complete." # End. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-13 5:20 ` Gerd Möllmann @ 2022-09-13 14:51 ` Sam Steingold 2022-09-14 5:46 ` Gerd Möllmann 2022-09-14 11:30 ` Gerd Möllmann 0 siblings, 2 replies; 27+ messages in thread From: Sam Steingold @ 2022-09-13 14:51 UTC (permalink / raw) To: Gerd Möllmann; +Cc: 57751 Hi Gerd, Thank you for such an informative reply. > * Gerd Möllmann <treq.zbryyznaa@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-13 14:51 ` Sam Steingold @ 2022-09-14 5:46 ` Gerd Möllmann 2022-09-14 18:36 ` Sam Steingold 2022-09-14 11:30 ` Gerd Möllmann 1 sibling, 1 reply; 27+ messages in thread From: Gerd Möllmann @ 2022-09-14 5:46 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 Sam Steingold <sds@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.) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-14 5:46 ` Gerd Möllmann @ 2022-09-14 18:36 ` Sam Steingold 2022-09-15 5:28 ` Gerd Möllmann 0 siblings, 1 reply; 27+ messages in thread From: Sam Steingold @ 2022-09-14 18:36 UTC (permalink / raw) To: Gerd Möllmann; +Cc: 57751 > * Gerd Möllmann <treq.zbryyznaa@tznvy.pbz> [2022-09-14 07:46:00 +0200]: > > Sam Steingold <sds@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-14 18:36 ` Sam Steingold @ 2022-09-15 5:28 ` Gerd Möllmann 2022-09-15 8:42 ` Gerd Möllmann 2022-09-15 16:35 ` Sam Steingold 0 siblings, 2 replies; 27+ messages in thread From: Gerd Möllmann @ 2022-09-15 5:28 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 Sam Steingold <sds@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 5:28 ` Gerd Möllmann @ 2022-09-15 8:42 ` Gerd Möllmann 2022-09-15 8:48 ` Gerd Möllmann ` (2 more replies) 2022-09-15 16:35 ` Sam Steingold 1 sibling, 3 replies; 27+ messages in thread From: Gerd Möllmann @ 2022-09-15 8:42 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 Gerd Möllmann <gerd.moellmann@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.) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 8:42 ` Gerd Möllmann @ 2022-09-15 8:48 ` Gerd Möllmann 2022-09-15 10:01 ` Gerd Möllmann 2022-09-15 9:23 ` Eli Zaretskii 2022-09-15 16:45 ` Sam Steingold 2 siblings, 1 reply; 27+ messages in thread From: Gerd Möllmann @ 2022-09-15 8:48 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 Gerd Möllmann <gerd.moellmann@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 8:48 ` Gerd Möllmann @ 2022-09-15 10:01 ` Gerd Möllmann 2022-09-15 12:10 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Gerd Möllmann @ 2022-09-15 10:01 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 Gerd Möllmann <gerd.moellmann@gmail.com> writes: > Gerd Möllmann <gerd.moellmann@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 10:01 ` Gerd Möllmann @ 2022-09-15 12:10 ` Eli Zaretskii 2022-09-15 15:12 ` Gerd Möllmann 2022-09-15 16:48 ` Sam Steingold 2022-09-15 22:25 ` Gregory Heytings 2 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2022-09-15 12:10 UTC (permalink / raw) To: Gerd Möllmann; +Cc: sds, 57751 > Cc: 57751@debbugs.gnu.org > From: Gerd Möllmann <gerd.moellmann@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 12:10 ` Eli Zaretskii @ 2022-09-15 15:12 ` Gerd Möllmann 0 siblings, 0 replies; 27+ messages in thread From: Gerd Möllmann @ 2022-09-15 15:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sds, 57751 Thanks. > Am 15.09.2022 um 14:10 schrieb Eli Zaretskii <eliz@gnu.org>: > > >> >> Cc: 57751@debbugs.gnu.org >> From: Gerd Möllmann <gerd.moellmann@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 10:01 ` Gerd Möllmann 2022-09-15 12:10 ` Eli Zaretskii @ 2022-09-15 16:48 ` Sam Steingold 2022-09-15 22:25 ` Gregory Heytings 2 siblings, 0 replies; 27+ messages in thread From: Sam Steingold @ 2022-09-15 16:48 UTC (permalink / raw) To: Gerd Möllmann; +Cc: 57751 > * Gerd Möllmann <treq.zbryyznaa@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 10:01 ` Gerd Möllmann 2022-09-15 12:10 ` Eli Zaretskii 2022-09-15 16:48 ` Sam Steingold @ 2022-09-15 22:25 ` Gregory Heytings 2022-09-15 22:41 ` Sam Steingold 2022-09-15 22:42 ` Sam Steingold 2 siblings, 2 replies; 27+ messages in thread From: Gregory Heytings @ 2022-09-15 22:25 UTC (permalink / raw) To: Gerd Möllmann; +Cc: Sam Steingold, 57751 > > 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 22:25 ` Gregory Heytings @ 2022-09-15 22:41 ` Sam Steingold 2022-09-15 22:42 ` Sam Steingold 1 sibling, 0 replies; 27+ messages in thread From: Sam Steingold @ 2022-09-15 22:41 UTC (permalink / raw) To: Gregory Heytings; +Cc: Gerd Möllmann, 57751 > * Gregory Heytings <tertbel@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 22:25 ` Gregory Heytings 2022-09-15 22:41 ` Sam Steingold @ 2022-09-15 22:42 ` Sam Steingold 2022-09-15 23:17 ` Gregory Heytings 1 sibling, 1 reply; 27+ messages in thread From: Sam Steingold @ 2022-09-15 22:42 UTC (permalink / raw) To: Gregory Heytings; +Cc: Gerd Möllmann, 57751 > * Gregory Heytings <tertbel@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 22:42 ` Sam Steingold @ 2022-09-15 23:17 ` Gregory Heytings 2022-09-16 5:40 ` Gerd Möllmann 0 siblings, 1 reply; 27+ messages in thread From: Gregory Heytings @ 2022-09-15 23:17 UTC (permalink / raw) To: Sam Steingold; +Cc: Gerd Möllmann, 57751 >> 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 23:17 ` Gregory Heytings @ 2022-09-16 5:40 ` Gerd Möllmann 2022-09-19 16:26 ` Sam Steingold 0 siblings, 1 reply; 27+ messages in thread From: Gerd Möllmann @ 2022-09-16 5:40 UTC (permalink / raw) To: Gregory Heytings; +Cc: Sam Steingold, 57751 Gregory Heytings <gregory@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-16 5:40 ` Gerd Möllmann @ 2022-09-19 16:26 ` Sam Steingold 2022-09-20 4:32 ` Gerd Möllmann 0 siblings, 1 reply; 27+ messages in thread From: Sam Steingold @ 2022-09-19 16:26 UTC (permalink / raw) To: Gerd Möllmann; +Cc: 57751 > * Gerd Möllmann <treq.zbryyznaa@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-19 16:26 ` Sam Steingold @ 2022-09-20 4:32 ` Gerd Möllmann 0 siblings, 0 replies; 27+ messages in thread From: Gerd Möllmann @ 2022-09-20 4:32 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 Sam Steingold <sds@gnu.org> writes: >> * Gerd Möllmann <treq.zbryyznaa@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 8:42 ` Gerd Möllmann 2022-09-15 8:48 ` Gerd Möllmann @ 2022-09-15 9:23 ` Eli Zaretskii 2022-09-15 9:37 ` Gerd Möllmann 2022-09-15 16:45 ` Sam Steingold 2 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2022-09-15 9:23 UTC (permalink / raw) To: Gerd Möllmann; +Cc: sds, 57751 > Cc: 57751@debbugs.gnu.org > From: Gerd Möllmann <gerd.moellmann@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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 9:23 ` Eli Zaretskii @ 2022-09-15 9:37 ` Gerd Möllmann 0 siblings, 0 replies; 27+ messages in thread From: Gerd Möllmann @ 2022-09-15 9:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sds, 57751 Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 8:42 ` Gerd Möllmann 2022-09-15 8:48 ` Gerd Möllmann 2022-09-15 9:23 ` Eli Zaretskii @ 2022-09-15 16:45 ` Sam Steingold 2 siblings, 0 replies; 27+ messages in thread From: Sam Steingold @ 2022-09-15 16:45 UTC (permalink / raw) To: Gerd Möllmann; +Cc: 57751 > * Gerd Möllmann <treq.zbryyznaa@tznvy.pbz> [2022-09-15 10:42:12 +0200]: > > Gerd Möllmann <gerd.moellmann@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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-15 5:28 ` Gerd Möllmann 2022-09-15 8:42 ` Gerd Möllmann @ 2022-09-15 16:35 ` Sam Steingold 1 sibling, 0 replies; 27+ messages in thread From: Sam Steingold @ 2022-09-15 16:35 UTC (permalink / raw) To: Gerd Möllmann; +Cc: 57751 > * Gerd Möllmann <treq.zbryyznaa@tznvy.pbz> [2022-09-15 07:28:17 +0200]: > > Sam Steingold <sds@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-13 14:51 ` Sam Steingold 2022-09-14 5:46 ` Gerd Möllmann @ 2022-09-14 11:30 ` Gerd Möllmann 2022-09-14 11:32 ` Gerd Möllmann 2022-09-14 18:20 ` Sam Steingold 1 sibling, 2 replies; 27+ messages in thread From: Gerd Möllmann @ 2022-09-14 11:30 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 Sam Steingold <sds@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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-14 11:30 ` Gerd Möllmann @ 2022-09-14 11:32 ` Gerd Möllmann 2022-09-14 18:20 ` Sam Steingold 1 sibling, 0 replies; 27+ messages in thread From: Gerd Möllmann @ 2022-09-14 11:32 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 Gerd Möllmann <gerd.moellmann@gmail.com> writes: > Sam Steingold <sds@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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-14 11:30 ` Gerd Möllmann 2022-09-14 11:32 ` Gerd Möllmann @ 2022-09-14 18:20 ` Sam Steingold 2022-09-15 4:49 ` Gerd Möllmann 1 sibling, 1 reply; 27+ messages in thread From: Sam Steingold @ 2022-09-14 18:20 UTC (permalink / raw) To: Gerd Möllmann; +Cc: 57751 > * Gerd Möllmann <treq.zbryyznaa@tznvy.pbz> [2022-09-14 13:30:18 +0200]: > > Sam Steingold <sds@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#57751: 29.0.50; crash in GC 2022-09-14 18:20 ` Sam Steingold @ 2022-09-15 4:49 ` Gerd Möllmann 0 siblings, 0 replies; 27+ messages in thread From: Gerd Möllmann @ 2022-09-15 4:49 UTC (permalink / raw) To: Sam Steingold; +Cc: 57751 Sam Steingold <sds@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2022-09-20 4:32 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-09-12 14:37 bug#57751: 29.0.50; crash in GC Sam Steingold 2022-09-13 5:20 ` Gerd Möllmann 2022-09-13 14:51 ` Sam Steingold 2022-09-14 5:46 ` Gerd Möllmann 2022-09-14 18:36 ` Sam Steingold 2022-09-15 5:28 ` Gerd Möllmann 2022-09-15 8:42 ` Gerd Möllmann 2022-09-15 8:48 ` Gerd Möllmann 2022-09-15 10:01 ` Gerd Möllmann 2022-09-15 12:10 ` Eli Zaretskii 2022-09-15 15:12 ` Gerd Möllmann 2022-09-15 16:48 ` Sam Steingold 2022-09-15 22:25 ` Gregory Heytings 2022-09-15 22:41 ` Sam Steingold 2022-09-15 22:42 ` Sam Steingold 2022-09-15 23:17 ` Gregory Heytings 2022-09-16 5:40 ` Gerd Möllmann 2022-09-19 16:26 ` Sam Steingold 2022-09-20 4:32 ` Gerd Möllmann 2022-09-15 9:23 ` Eli Zaretskii 2022-09-15 9:37 ` Gerd Möllmann 2022-09-15 16:45 ` Sam Steingold 2022-09-15 16:35 ` Sam Steingold 2022-09-14 11:30 ` Gerd Möllmann 2022-09-14 11:32 ` Gerd Möllmann 2022-09-14 18:20 ` Sam Steingold 2022-09-15 4:49 ` Gerd Möllmann
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.