* bug#32503: 26.1; Byte-compiled functions don't hash consistently @ 2018-08-22 19:00 Adam Porter 2018-08-23 1:42 ` Tom Tromey 0 siblings, 1 reply; 3+ messages in thread From: Adam Porter @ 2018-08-22 19:00 UTC (permalink / raw) To: 32503 I noticed that byte-compiled functions don't hash consistently. Here's an ECM from Noam Postavsky <https://github.com/skeeto/emacs-memoize/pull/10#issuecomment-415066682>: (let ((obj1 (byte-compile (lambda (x) x))) (obj2 (byte-compile (lambda (x) x)))) (list (equal obj1 obj2) (eq obj1 obj2) (= (sxhash obj1) (sxhash obj2)))) ;=> (t nil nil) According to "(elisp) Defining Hash": If two objects OBJ1 and OBJ2 are equal, then ‘(sxhash OBJ1)’ and ‘(sxhash OBJ2)’ are the same integer. This makes it impossible to use byte-compiled functions as keys or parts of keys in hash tables. A workaround is to `prin1-to-string` the byte-compiled function and use that as the key. Thanks. ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#32503: 26.1; Byte-compiled functions don't hash consistently 2018-08-22 19:00 bug#32503: 26.1; Byte-compiled functions don't hash consistently Adam Porter @ 2018-08-23 1:42 ` Tom Tromey 0 siblings, 0 replies; 3+ messages in thread From: Tom Tromey @ 2018-08-23 1:42 UTC (permalink / raw) To: Adam Porter; +Cc: 32503 Adam> I noticed that byte-compiled functions don't hash consistently. The Lisp_Vectorlike case in Fequal has a number of special cases which don't seem to be reflected in sxhash: if (OVERLAYP (o1)) [...] if (MARKERP (o1)) [...] if (WINDOW_CONFIGURATIONP (o1)) [...] /* Aside from them, only true vectors, char-tables, compiled functions, and fonts (font-spec, font-entity, font-object) are sensible to compare, so eliminate the others now. */ (Bignums and bool vectors are special-cased as well but are handled in sxhash.) This is followed by code to loop over the pseudovector's elements. However, the Lisp_Vectorlike case in sxhash doesn't do any of this. Probably there should be a rule that adding a new type should necessitate adding a new hasher (much like how print syntax is needed); or certainly if the type has non-trivial equal behavior. Tom ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded @ 2020-01-04 1:49 NiwTinray via Bug reports for GNU Emacs, the Swiss army knife of text editors 2020-01-04 9:17 ` Eli Zaretskii 0 siblings, 1 reply; 3+ messages in thread From: NiwTinray via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-01-04 1:49 UTC (permalink / raw) To: 38912 Hi, Emacs Dev, I was testing the new portable dumper with my personal Emacs. When I loaded my dumped file, Emacs crashed on segmentation fault. After tracking down the issue, I found the issues is caused by the undo-tree mode in package "evil". To reproduce the bug, try this: emacs --batch -f package-initialize --eval='(use-package evil :ensure t)' --eval='(dump-emacs-portable "test.pdmp")' && emacs --dump-file test.pdmp If I turned off the global-undo-tree-mode manually, it won't crash: emacs --batch -f package-initialize --eval='(use-package evil :ensure t)' --eval='(global-undo-tree-mode -1)' --eval='(dump-emacs-portable "test.pdmp")' && emacs --dump-file test.pdmp So the problem must be exist in the undo-tree-mode. I don't have the knowledge/techniques to track down the bug further. Please help me investigate this! Backtrace on crash: #0 0x00000000004f1240 in Fcurrent_active_maps (olp=olp@entry=0x30, position=position@entry=0x0) at keymap.c:1541 #1 0x00000000004f167d in Fkey_binding (key=0x7fffefba745d, accept_default=0x0, no_remap=0x0, position=0x0) at keymap.c:1681 #2 0x00000000005546a3 in Ffuncall (nargs=2, args=args@entry=0x7fffffffd5d0) at eval.c:2794 #3 0x0000000000588d28 in exec_byte_code (bytestr=<optimized out>, vector=0x7fffefba2715, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x7fffefba2718) at bytecode.c:633 #4 0x000000000055439f in funcall_lambda (fun=0x7fffffffd5e3, nargs=nargs@entry=0, arg_vector=0x7fffefba2718, arg_vector@entry=0x7fffffffd768) at eval.c:2989 #5 0x00000000005545ef in Ffuncall (nargs=1, args=args@entry=0x7fffffffd760) at eval.c:2808 #6 0x0000000000588d28 in exec_byte_code (bytestr=<optimized out>, vector=0x7fffefba262d, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x7fffefba2630) at bytecode.c:633 #7 0x000000000055439f in funcall_lambda (fun=0x7fffffffd79e, nargs=nargs@entry=0, arg_vector=0x7fffefba2630, arg_vector@entry=0x7fffffffd958) at eval.c:2989 #8 0x00000000005545ef in Ffuncall (nargs=1, args=0x7fffffffd950) at eval.c:2808 #9 0x00000000005546e9 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2435 #10 0x00000000005534a5 in run_hook_with_args (nargs=1, args=0x7fffffffd950, funcall=0x5546e0 <funcall_nil>) at eval.c:2612 #11 0x0000000000553616 in Frun_hook_with_args (args=0x7fffffffd950, nargs=1) at eval.c:2477 #12 run_hook (hook=0x7fffeefb53f0) at eval.c:2625 #13 Frun_hooks (nargs=1, args=0x7fffffffd9f8) at eval.c:2459 #14 0x00000000005546a3 in Ffuncall (nargs=2, args=args@entry=0x7fffffffd9f0) at eval.c:2794 #15 0x0000000000588d28 in exec_byte_code (bytestr=<optimized out>, vector=0x7fffefab5415, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7fffefab5418) at bytecode.c:633 #16 0x000000000055439f in funcall_lambda (fun=0x7fffffffda66, nargs=nargs@entry=1, arg_vector=0x7fffefab5418, arg_vector@entry=0x7fffffffdbd0) at eval.c:2989 #17 0x00000000005545ef in Ffuncall (nargs=2, args=args@entry=0x7fffffffdbc8) at eval.c:2808 #18 0x0000000000588d28 in exec_byte_code (bytestr=<optimized out>, vector=0x7fffefc794ad, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x7fffefc794b0) at bytecode.c:633 #19 0x000000000055439f in funcall_lambda (fun=0x7fffffffdbf1, nargs=nargs@entry=0, arg_vector=0x7fffefc794b0, arg_vector@entry=0x7fffffffdd50) at eval.c:2989 #20 0x00000000005545ef in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffffdd48) at eval.c:2808 #21 0x0000000000554758 in call0 (fn=0x7fffef08c260) at eval.c:2647 #22 0x000000000050a4ff in get_minibuffer (depth=depth@entry=0) at minibuf.c:754 #23 0x0000000000501283 in init_buffer () at buffer.c:5430 #24 0x00000000004139ba in main (argc=3, argv=<optimized out>) at emacs.c:1777 In GNU Emacs 27.0.60 (build 1, x86_64-pc-linux-gnu) of 2020-01-01 built on omnisky Repository revision: 186152ba400b58d2d278c52d2e3d896decae767e Repository branch: emacs-27 System Description: Ubuntu 16.04.6 LTS Recent messages: Saving file /home/ntr/.config/emacs/custom.el... Wrote /home/ntr/.config/emacs/emacs.saves/.!home!ntr!.config!emacs!custom.el.~undo-tree~ Wrote /home/ntr/.config/emacs/custom.el helm-M-x: Package ‘evil-20190729.704’ is used by ‘evil-multiedit’ as dependency, not deleting Mark saved where search started Package ‘highlight-parentheses-20180704.1102’ deleted. Mark saved where search started Saving file /home/ntr/.config/emacs/bunny-core-packages.el... Wrote /home/ntr/.config/emacs/emacs.saves/.!home!ntr!.config!emacs!bunny-core-packages.el.~undo-tree~ Wrote /home/ntr/.config/emacs/bunny-core-packages.el Configured using: 'configure --with-x-toolkit=no' Configured features: XPM JPEG TIFF GIF PNG SOUND GSETTINGS GLIB NOTIFY INOTIFY GNUTLS FREETYPE HARFBUZZ XFT ZLIB OLDXMENU X11 XDBE XIM MODULES THREADS JSON PDUMPER GMP Important settings: value of $LC_ALL: en_US.UTF-8 value of $LC_CTYPE: zh_CN.UTF-8 value of $LC_MONETARY: zh_CN.UTF-8 value of $LC_NUMERIC: zh_CN.UTF-8 value of $LC_TIME: zh_CN.UTF-8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: doom-modeline-mode: t recentf-mode: t xterm-mouse-mode: t display-time-mode: t workgroups-mode: t keyfreq-autosave-mode: t keyfreq-mode: t global-magit-file-mode: t magit-file-mode: t magit-auto-revert-mode: t global-git-commit-mode: t async-bytecomp-package-mode: t company-statistics-mode: t global-company-mode: t company-mode: t global-hungry-delete-mode: t hungry-delete-mode: t eyebrowse-mode: t helm-mode: t override-global-mode: t delete-selection-mode: t auto-revert-mode: t global-hl-line-mode: t which-key-mode: t global-evil-matchit-mode: t evil-matchit-mode: t global-evil-collection-unimpaired-mode: t evil-collection-unimpaired-mode: t evil-leader-mode: t global-undo-tree-mode: t undo-tree-mode: t shell-dirtrack-mode: t evil-mode: t evil-local-mode: t global-hl-todo-mode: t hl-todo-mode: t global-highlight-parentheses-mode: t highlight-parentheses-mode: t aggressive-indent-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (evil-matchit-simple helm-ring em-unix em-term em-script em-prompt em-ls em-hist em-pred em-dirs esh-var em-cmpl em-basic em-banner em-alias esh-mode eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups shadow sort mail-extr emacsbug sendmail tabify ido face-remap image-file mule-util view lsp-clients lsp-haxe lsp-erlang lsp-fsharp lsp-metals lsp-elm lsp-dart lsp-clojure lsp-go lsp-xml lsp-css lsp-intelephense lsp-vetur lsp-html lsp-solargraph lsp-rust lsp-pyls lsp helm-for-files helm-bookmark helm-adaptive helm-external helm-net ffap vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc vc-dispatcher jka-compr eieio-opt speedbar sb-image ezimage dframe help-fns radix-tree so-long winner helm-command helm-elisp helm-eval edebug backtrace helm-info term/xterm xterm doom-modeline doom-modeline-segments doom-modeline-env doom-modeline-core recentf magit-bookmark bookmark ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util xt-mouse bunny-sshfs flymake-diagnostic-at-point popup lsp-python-ms python-el-fgallina-expansions python tramp-sh tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat parse-time iso8601 ls-lisp company-lsp lsp-mode ewoc markdown-mode tree-widget spinner network-stream nsm inline ht em-glob esh-util dash-functional bindat flymake-proc flymake warnings bunny-pyenv eldoc-eval all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons memoize eshell-git-prompt leuven-theme time bunny-insert-surroundings bunny-krws bunny-company-simple-complete bunny-eshell-extensions bunny-terminal-here bunny-workgroups bunny-register-jumper bunny-h5ls bunny-prettify-json-file web-server web-server-status-codes keyfreq evil-magit magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode magit-core magit-autorevert magit-margin magit-transient magit-process magit-mode git-commit magit-git magit-section magit-utils crm log-edit message rmc rfc822 mml mml-sec epa derived epg epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader pcvs-util add-log with-editor async-bytecomp server git-timemachine transient vc-git diff-mode org-preview-html eww mm-url gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mail-utils mm-util mail-prsvr url-queue shr text-property-search puny svg xml the-org-mode-expansions org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list org-faces org-entities time-date noutline outline org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys org-compat org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs company-statistics company-oddmuse company-keywords company-etags etags fileloop generator company-gtags company-dabbrev-code company-dabbrev company-files company-capf company-cmake company-xcode company-clang company-semantic company-eclim company-template company-bbdb company pcase multi-term shell-pop term disp-table ehelp htmlize hungry-delete expand-region text-mode-expansions html-mode-expansions er-basic-expansions expand-region-core expand-region-custom golden-ratio eyebrowse use-package-diminish buffer-move transpose-frame helm-ag helm-descbinds helm-projectile cus-edit cus-start cus-load wid-edit helm-mode helm-files helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp format-spec helm-utils helm-help helm-types helm helm-source eieio-compat helm-multi-match helm-lib async use-package-bind-key bind-key counsel xdg xref project swiper ivy delsel colir ivy-overlay ace-window avy ace-jump-zap ace-jump-mode cl ranger autorevert filenotify hl-line evil-collection-dired dired dired-loaddefs evil-collection-neotree neotree projectile grep compile ibuf-ext ibuffer ibuffer-loaddefs shrink-path rx f s dash which-key evil-multiedit iedit iedit-lib evil-nerd-commenter evil-nerd-commenter-operator evil-nerd-commenter-sdk sgml-mode dom evil-matchit evil-matchit-sdk evil-collection-unimpaired evil-collection bunny-minor-mode-leader-keymap zone-rainbow color zone symbol-overlay evil-leader evil evil-integration undo-tree diff evil-maps evil-commands reveal flyspell ispell evil-jumps evil-command-window evil-types evil-search evil-ex shell pcomplete comint ansi-color evil-macros evil-repeat evil-states evil-core advice evil-common windmove thingatpt rect evil-digraphs evil-vars edmacro kmacro hl-todo posframe rainbow-delimiters highlight-parentheses move-text macrostep ring pp exec-path-from-shell try url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap anaphora aggressive-indent easy-mmode cl-extra help-mode use-package-ensure use-package-core finder-inf info package easymenu browse-url url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic 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 charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads inotify dynamic-setting system-font-setting font-render-setting x multi-tty make-network-process emacs) Memory information: ((conses 16 632937 99192) (symbols 48 53853 52) (strings 32 181171 13075) (string-bytes 1 5457906) (vectors 16 89834) (vector-slots 8 1780900 209238) (floats 8 893 401) (intervals 56 24129 5564) (buffers 1000 48) (heap 1024 49509 3144)) ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-04 1:49 bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded NiwTinray via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-01-04 9:17 ` Eli Zaretskii [not found] ` <D1473DD8-48F8-4204-80B5-BE6396B8B668@icloud.com> 0 siblings, 1 reply; 3+ messages in thread From: Eli Zaretskii @ 2020-01-04 9:17 UTC (permalink / raw) To: NiwTinray; +Cc: 38912 > Date: Sat, 4 Jan 2020 09:49:14 +0800 > From: NiwTinray via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> > > I was testing the new portable dumper with my personal Emacs. When I > loaded my dumped file, Emacs crashed on segmentation fault. > After tracking down the issue, I found the issues is caused by the > undo-tree mode in package "evil". > To reproduce the bug, try this: > > emacs --batch -f package-initialize --eval='(use-package evil :ensure > t)' --eval='(dump-emacs-portable "test.pdmp")' && emacs --dump-file > test.pdmp I cannot reproduce this from "emacs -Q" because 'use-package' is not a known function. Can you show a recipe starting from "emacs -Q", please? Also, does this happen if you add -Q to the Emacs invocation after dumping? If not, there's more detail missing in your report: the customizations in your init files. In addition, please also show the Lisp-level backtrace from the crash, by using the xbacktrace command (it is defined in the src/.gdbinit file in the Emacs source tree). > Backtrace on crash: > #0 0x00000000004f1240 in Fcurrent_active_maps (olp=olp@entry=0x30, position=position@entry=0x0) at keymap.c:1541 GDB usually displays the fatal signal that killed the program; can you show that part as well? Thanks. ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <D1473DD8-48F8-4204-80B5-BE6396B8B668@icloud.com>]
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded [not found] ` <D1473DD8-48F8-4204-80B5-BE6396B8B668@icloud.com> @ 2020-01-05 18:45 ` Eli Zaretskii 2020-01-06 17:10 ` Daniel Colascione 0 siblings, 1 reply; 3+ messages in thread From: Eli Zaretskii @ 2020-01-05 18:45 UTC (permalink / raw) To: NiwTinray, Daniel Colascione; +Cc: 38912 [Please use "Reply All" to reply, so that the bug address is kept on the CC list.] > From: NiwTinray <niwtrx@icloud.com> > Date: Sun, 5 Jan 2020 13:25:07 +0800 > > > I cannot reproduce this from "emacs -Q" because 'use-package' is not a > > known function. Can you show a recipe starting from "emacs -Q", > > please? > > Here. I've attached a minimal script file that helps reproduce this bug. > > (require 'package) > (package-initialize) > (add-to-list 'package-archives > '("melpa-stable" . "https://stable.melpa.org/packages/") t) > (unless (package-installed-p 'evil) > (package-refresh-contents) > (package-install 'evil)) > (require 'evil) > (dump-emacs-portable "/tmp/test.pdmp") > > The script downloads the package "evil" from Melpa stable, load the evil package > and dumps an image to /tmp/test.pdmp. > > > Also, does this happen if you add -Q to the Emacs invocation after > > dumping? If not, there's more detail missing in your report: the > > customizations in your init files. > > > Sure. Please download this file, and run the command: > > emacs --batch -Q --script evil.el > > To see the bug happen, load the test.pdmp file: > > emacs -Q --dump-file /tmp/test.pdmp > > You should see a segmentation fault: > > [1] 23369 segmentation fault (core dumped) emacs -Q --dump-file /tmp/test.pdmp > > I run debugger inside src/.gdbinit using the command: > > gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp > > And logged backtrace. See my second attachment: > > (base) omnisky :: ~/emacs/src ‹emacs-27*› » gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp > GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 > Copyright (C) 2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ./emacs...done. > warning: File "/home/ntr/emacs/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /home/ntr/emacs/src/.gdbinit > line to your configuration file "/home/ntr/.gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "/home/ntr/.gdbinit". > For more information about this security protection see the > "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: > info "(gdb)Auto-loading safe path" > SIGINT is used by the debugger. > Are you sure you want to change it? (y or n) [answered Y; input not from terminal] > Environment variable "DISPLAY" not defined. > TERM = xterm-24bits > Breakpoint 1 at 0x411df0: file emacs.c, line 370. > Breakpoint 2 at 0x4bfe60: file xterm.c, line 10130. > (gdb) r > Starting program: /home/ntr/emacs/src/emacs --dump-file /tmp/test.pdmp > /home/ntr/emacs/src/emacs: /raid_sdc/home/ntr/anaconda3/lib/libtiff.so.5: no version information available (required by /home/ntr/emacs/src/emacs) > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004f12d0 in Fcurrent_active_maps (olp=olp@entry=XIL(0x30), position=position@entry=XIL(0)) at keymap.c:1541 > 1541 && NILP (KVAR (current_kboard, Voverriding_terminal_local_map)) > (gdb) xbacktrace > "key-binding" (0xffffd5c8) > "turn-on-undo-tree-mode" (0xffffd758) > "global-undo-tree-mode-enable-in-buffers" (0xffffd948) > "run-hooks" (0xffffd9e8) > "run-mode-hooks" (0xffffdbc0) > "minibuffer-inactive-mode" (0xffffdd40) > (gdb) In my debug build of Emacs 27.0.60 I get an assertion violation while dumping, which probably is already a sign of trouble. Daniel, any ideas? Here's the backtrace from the assertion violation, and some data involved in the assertion: dumping fingerprint: 79862409ba15bcbb091a8b1aa5b942cc3283f12f123a69372f5cfe59de047ba9 pdumper.c:2684: Emacs fatal error: assertion failed: EQ (expected_value, found_value) Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:371 371 signal (sig, SIG_DFL); (gdb) bt #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:371 #1 0x01317f22 in die ( msg=0x19bac5c <WEIGHT_STRONG+2544> "EQ (expected_value, found_value)", file=0x19ba210 <dump_magic+16> "pdumper.c", line=2684) at alloc.c:7246 #2 0x01326817 in check_hash_table_rehash (table_orig=XIL(0xa000000006288090)) at pdumper.c:2684 #3 0x01326a6c in dump_hash_table (ctx=0x82d1f0, object=XIL(0xa000000006288090), offset=-4) at pdumper.c:2725 #4 0x013279c5 in dump_vectorlike (ctx=0x82d1f0, lv=XIL(0xa000000006288090), offset=-4) at pdumper.c:2991 #5 0x01327f92 in dump_object (ctx=0x82d1f0, object=XIL(0xa000000006288090)) at pdumper.c:3127 #6 0x0132ace3 in dump_drain_deferred_hash_tables (ctx=0x82d1f0) at pdumper.c:3977 #7 0x0132b4ca in Fdump_emacs_portable (filename=XIL(0x8000000006d24008), track_referrers=XIL(0)) at pdumper.c:4148 #8 0x013825de in eval_sub (form=XIL(0xc0000000067b2150)) at eval.c:2276 #9 0x0137aec2 in Fprogn (body=XIL(0)) at eval.c:462 #10 0x01382182 in eval_sub (form=XIL(0xc0000000067b2090)) at eval.c:2226 #11 0x013819e8 in Feval (form=XIL(0xc0000000067b2090), lexical=XIL(0x30)) at eval.c:2102 #12 0x01384ecc in funcall_subr (subr=0x1960b00 <Seval>, numargs=2, args=0x82d978) at eval.c:2869 #13 0x013848f9 in Ffuncall (nargs=3, args=0x82d970) at eval.c:2794 #14 0x01427e37 in exec_byte_code (bytestr=XIL(0x800000000612e1e0), vector=XIL(0xa00000000612d0f8), maxdepth=make_fixnum(25), args_template=make_fixnum(257), nargs=1, args=0x82e378) at bytecode.c:633 #15 0x01385a11 in funcall_lambda (fun=XIL(0xa00000000612d0c8), nargs=1, arg_vector=0x82e370) at eval.c:2989 #16 0x01384953 in Ffuncall (nargs=2, args=0x82e368) at eval.c:2796 #17 0x01427e37 in exec_byte_code (bytestr=XIL(0x8000000006131a80), vector=XIL(0xa00000000612e450), maxdepth=make_fixnum(14), args_template=make_fixnum(0), nargs=0, args=0x82efa8) at bytecode.c:633 #18 0x01385a11 in funcall_lambda (fun=XIL(0xa00000000612e420), nargs=0, arg_vector=0x82efa8) at eval.c:2989 #19 0x01384953 in Ffuncall (nargs=1, args=0x82efa0) at eval.c:2796 #20 0x01427e37 in exec_byte_code (bytestr=XIL(0x8000000006132488), vector=XIL(0xa000000006131c20), maxdepth=make_fixnum(12), args_template=make_fixnum(0), nargs=0, args=0x82f680) at bytecode.c:633 #21 0x01385a11 in funcall_lambda (fun=XIL(0xa000000006131bf0), nargs=0, arg_vector=0x82f680) at eval.c:2989 #22 0x01385519 in apply_lambda (fun=XIL(0xa000000006131bf0), args=XIL(0), count=4) at eval.c:2926 #23 0x01382b51 in eval_sub (form=XIL(0xc000000006278198)) at eval.c:2318 #24 0x013819e8 in Feval (form=XIL(0xc000000006278198), lexical=XIL(0)) at eval.c:2102 #25 0x011df7a3 in top_level_2 () at keyboard.c:1100 #26 0x0137f02d in internal_condition_case (bfun=0x11df76d <top_level_2>, handlers=XIL(0x90), hfun=0x11def2f <cmd_error>) at eval.c:1355 #27 0x011df818 in top_level_1 (ignore=XIL(0)) at keyboard.c:1108 #28 0x0137e1f8 in internal_catch (tag=XIL(0xdfe0), func=0x11df7a9 <top_level_1>, arg=XIL(0)) at eval.c:1116 #29 0x011df679 in command_loop () at keyboard.c:1069 #30 0x011de9b7 in recursive_edit_1 () at keyboard.c:714 #31 0x011dec2d in Frecursive_edit () at keyboard.c:786 #32 0x011d3547 in main (argc=4, argv=0xa42848) at emacs.c:2054 Lisp Backtrace: "dump-emacs-portable" (0x82d468) "progn" (0x82d658) "eval" (0x82d978) "command-line-1" (0x82e370) "command-line" (0x82efa8) "normal-top-level" (0x82f680) (gdb) fr 5 #5 0x01327f92 in dump_object (ctx=0x82d1f0, object=XIL(0xa000000006288090)) at pdumper.c:3127 3127 offset = dump_vectorlike (ctx, object, offset); (gdb) p object $1 = XIL(0xa000000006288090) (gdb) xtype Lisp_Vectorlike PVEC_HASH_TABLE (gdb) xhashtable $2 = (struct Lisp_Hash_Table *) 0x6288090 (gdb) p *$ $3 = { header = { size = 1291882500 }, weak = XIL(0), hash = XIL(0xa0000000068192c0), next = XIL(0xa0000000068194d0), index = XIL(0xa0000000068196e0), count = 13, next_free = 13, purecopy = false, mutable = true, rehash_threshold = 0.8125, rehash_size = 0.5, key_and_value = XIL(0xa000000005fbe6f8), test = { name = XIL(0x5610), user_hash_function = XIL(0), user_cmp_function = XIL(0), cmpfn = 0x13a7ffe <cmpfn_equal>, hashfn = 0x13a8107 <hashfn_equal> }, next_weak = 0x0 } (gdb) p $2->key_and_value $4 = XIL(0xa000000005fbe6f8) (gdb) xtype Lisp_Vectorlike PVEC_NORMAL_VECTOR (gdb) xvector $5 = (struct Lisp_Vector *) 0x5fbe6f8 0 (gdb) p $2->test.name $6 = XIL(0x5610) (gdb) xtype Lisp_Symbol (gdb) xsymbol $7 = (struct Lisp_Symbol *) 0x1bc74d0 <lispsym+22032> "equal" (gdb) p expected_value $8 = XIL(0xa000000006a527d8) (gdb) xtype Lisp_Vectorlike PVEC_COMPILED (gdb) xcompiled $9 = (struct Lisp_Vector *) 0x6a527d8 {make_fixnum(771), XIL(0x8000000006ab8250), XIL(0xa000000006a36558), make_fixnum(13), XIL(0x8000000006ab81c0)} (gdb) p found_value $10 = XIL(0xa000000006c2fc00) (gdb) xtype Lisp_Vectorlike PVEC_COMPILED (gdb) xcompiled $11 = (struct Lisp_Vector *) 0x6c2fc00 {make_fixnum(771), XIL(0x80000000069d21b0), XIL(0xa000000006c2fba0), make_fixnum(13), XIL(0x8000000006a412b0)} (gdb) ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-05 18:45 ` Eli Zaretskii @ 2020-01-06 17:10 ` Daniel Colascione 2020-03-05 7:14 ` Eli Zaretskii 0 siblings, 1 reply; 3+ messages in thread From: Daniel Colascione @ 2020-01-06 17:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: NiwTinray, 38912 > [Please use "Reply All" to reply, so that the bug address is kept on > the CC list.] > >> From: NiwTinray <niwtrx@icloud.com> >> Date: Sun, 5 Jan 2020 13:25:07 +0800 >> >> > I cannot reproduce this from "emacs -Q" because 'use-package' is not a >> > known function. Can you show a recipe starting from "emacs -Q", >> > please? >> >> Here. I've attached a minimal script file that helps reproduce this bug. >> >> (require 'package) >> (package-initialize) >> (add-to-list 'package-archives >> '("melpa-stable" . "https://stable.melpa.org/packages/") t) >> (unless (package-installed-p 'evil) >> (package-refresh-contents) >> (package-install 'evil)) >> (require 'evil) >> (dump-emacs-portable "/tmp/test.pdmp") >> >> The script downloads the package "evil" from Melpa stable, load the evil >> package >> and dumps an image to /tmp/test.pdmp. >> >> > Also, does this happen if you add -Q to the Emacs invocation after >> > dumping? If not, there's more detail missing in your report: the >> > customizations in your init files. >> >> >> Sure. Please download this file, and run the command: >> >> emacs --batch -Q --script evil.el >> >> To see the bug happen, load the test.pdmp file: >> >> emacs -Q --dump-file /tmp/test.pdmp >> >> You should see a segmentation fault: >> >> [1] 23369 segmentation fault (core dumped) emacs -Q --dump-file >> /tmp/test.pdmp >> >> I run debugger inside src/.gdbinit using the command: >> >> gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp >> >> And logged backtrace. See my second attachment: >> >> (base) omnisky :: ~/emacs/src â¹emacs-27*⺠» gdb -x .gdbinit --args >> ./emacs --dump-file /tmp/test.pdmp >> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 >> Copyright (C) 2016 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> <http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>. >> Find the GDB manual and other documentation resources online at: >> <http://www.gnu.org/software/gdb/documentation/>. >> For help, type "help". >> Type "apropos word" to search for commands related to "word"... >> Reading symbols from ./emacs...done. >> warning: File "/home/ntr/emacs/src/.gdbinit" auto-loading has been >> declined by your `auto-load safe-path' set to >> "$debugdir:$datadir/auto-load". >> To enable execution of this file add >> add-auto-load-safe-path /home/ntr/emacs/src/.gdbinit >> line to your configuration file "/home/ntr/.gdbinit". >> To completely disable this security protection add >> set auto-load safe-path / >> line to your configuration file "/home/ntr/.gdbinit". >> For more information about this security protection see the >> "Auto-loading safe path" section in the GDB manual. E.g., run from the >> shell: >> info "(gdb)Auto-loading safe path" >> SIGINT is used by the debugger. >> Are you sure you want to change it? (y or n) [answered Y; input not from >> terminal] >> Environment variable "DISPLAY" not defined. >> TERM = xterm-24bits >> Breakpoint 1 at 0x411df0: file emacs.c, line 370. >> Breakpoint 2 at 0x4bfe60: file xterm.c, line 10130. >> (gdb) r >> Starting program: /home/ntr/emacs/src/emacs --dump-file /tmp/test.pdmp >> /home/ntr/emacs/src/emacs: >> /raid_sdc/home/ntr/anaconda3/lib/libtiff.so.5: no version information >> available (required by /home/ntr/emacs/src/emacs) >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library >> "/lib/x86_64-linux-gnu/libthread_db.so.1". >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00000000004f12d0 in Fcurrent_active_maps (olp=olp@entry=XIL(0x30), >> position=position@entry=XIL(0)) at keymap.c:1541 >> 1541 && NILP (KVAR (current_kboard, >> Voverriding_terminal_local_map)) >> (gdb) xbacktrace >> "key-binding" (0xffffd5c8) >> "turn-on-undo-tree-mode" (0xffffd758) >> "global-undo-tree-mode-enable-in-buffers" (0xffffd948) >> "run-hooks" (0xffffd9e8) >> "run-mode-hooks" (0xffffdbc0) >> "minibuffer-inactive-mode" (0xffffdd40) >> (gdb) > > In my debug build of Emacs 27.0.60 I get an assertion violation while > dumping, which probably is already a sign of trouble. > > Daniel, any ideas? I haven't had a chance over the past few days to repro this problem, but I hope to do so this weeekend. The messages about the assertion failure *during* dumping do seem likely unrelated. The easiest way to debug this particular crash is with rr. Run the original test as "rr record emacs [args]", then run "rr replay". The latter will dump you in a GDB prompt. Type "cont" and run the replay of Emacs until you get to the SIGSEGV. Run "watch -l [expression]" to break out of execution whenever that value changes, then run "reverse-cont" to run the replay *backwards* until you get to the code that changed the variable with the bad value. ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-01-06 17:10 ` Daniel Colascione @ 2020-03-05 7:14 ` Eli Zaretskii 2020-03-09 2:15 ` Daniel Colascione 0 siblings, 1 reply; 3+ messages in thread From: Eli Zaretskii @ 2020-03-05 7:14 UTC (permalink / raw) To: Daniel Colascione; +Cc: niwtrx, 38912 Ping! Any news in debugging this? > Date: Mon, 6 Jan 2020 09:10:20 -0800 > From: "Daniel Colascione" <dancol@dancol.org> > Cc: "NiwTinray" <niwtrx@icloud.com>, > "Daniel Colascione" <dancol@dancol.org>, > 38912@debbugs.gnu.org > > > [Please use "Reply All" to reply, so that the bug address is kept on > > the CC list.] > > > >> From: NiwTinray <niwtrx@icloud.com> > >> Date: Sun, 5 Jan 2020 13:25:07 +0800 > >> > >> > I cannot reproduce this from "emacs -Q" because 'use-package' is not a > >> > known function. Can you show a recipe starting from "emacs -Q", > >> > please? > >> > >> Here. I've attached a minimal script file that helps reproduce this bug. > >> > >> (require 'package) > >> (package-initialize) > >> (add-to-list 'package-archives > >> '("melpa-stable" . "https://stable.melpa.org/packages/") t) > >> (unless (package-installed-p 'evil) > >> (package-refresh-contents) > >> (package-install 'evil)) > >> (require 'evil) > >> (dump-emacs-portable "/tmp/test.pdmp") > >> > >> The script downloads the package "evil" from Melpa stable, load the evil > >> package > >> and dumps an image to /tmp/test.pdmp. > >> > >> > Also, does this happen if you add -Q to the Emacs invocation after > >> > dumping? If not, there's more detail missing in your report: the > >> > customizations in your init files. > >> > >> > >> Sure. Please download this file, and run the command: > >> > >> emacs --batch -Q --script evil.el > >> > >> To see the bug happen, load the test.pdmp file: > >> > >> emacs -Q --dump-file /tmp/test.pdmp > >> > >> You should see a segmentation fault: > >> > >> [1] 23369 segmentation fault (core dumped) emacs -Q --dump-file > >> /tmp/test.pdmp > >> > >> I run debugger inside src/.gdbinit using the command: > >> > >> gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp > >> > >> And logged backtrace. See my second attachment: > >> > >> (base) omnisky :: ~/emacs/src â¹emacs-27*⺠» gdb -x .gdbinit --args > >> ./emacs --dump-file /tmp/test.pdmp > >> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 > >> Copyright (C) 2016 Free Software Foundation, Inc. > >> License GPLv3+: GNU GPL version 3 or later > >> <http://gnu.org/licenses/gpl.html> > >> This is free software: you are free to change and redistribute it. > >> There is NO WARRANTY, to the extent permitted by law. Type "show > >> copying" > >> and "show warranty" for details. > >> This GDB was configured as "x86_64-linux-gnu". > >> Type "show configuration" for configuration details. > >> For bug reporting instructions, please see: > >> <http://www.gnu.org/software/gdb/bugs/>. > >> Find the GDB manual and other documentation resources online at: > >> <http://www.gnu.org/software/gdb/documentation/>. > >> For help, type "help". > >> Type "apropos word" to search for commands related to "word"... > >> Reading symbols from ./emacs...done. > >> warning: File "/home/ntr/emacs/src/.gdbinit" auto-loading has been > >> declined by your `auto-load safe-path' set to > >> "$debugdir:$datadir/auto-load". > >> To enable execution of this file add > >> add-auto-load-safe-path /home/ntr/emacs/src/.gdbinit > >> line to your configuration file "/home/ntr/.gdbinit". > >> To completely disable this security protection add > >> set auto-load safe-path / > >> line to your configuration file "/home/ntr/.gdbinit". > >> For more information about this security protection see the > >> "Auto-loading safe path" section in the GDB manual. E.g., run from the > >> shell: > >> info "(gdb)Auto-loading safe path" > >> SIGINT is used by the debugger. > >> Are you sure you want to change it? (y or n) [answered Y; input not from > >> terminal] > >> Environment variable "DISPLAY" not defined. > >> TERM = xterm-24bits > >> Breakpoint 1 at 0x411df0: file emacs.c, line 370. > >> Breakpoint 2 at 0x4bfe60: file xterm.c, line 10130. > >> (gdb) r > >> Starting program: /home/ntr/emacs/src/emacs --dump-file /tmp/test.pdmp > >> /home/ntr/emacs/src/emacs: > >> /raid_sdc/home/ntr/anaconda3/lib/libtiff.so.5: no version information > >> available (required by /home/ntr/emacs/src/emacs) > >> [Thread debugging using libthread_db enabled] > >> Using host libthread_db library > >> "/lib/x86_64-linux-gnu/libthread_db.so.1". > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> 0x00000000004f12d0 in Fcurrent_active_maps (olp=olp@entry=XIL(0x30), > >> position=position@entry=XIL(0)) at keymap.c:1541 > >> 1541 && NILP (KVAR (current_kboard, > >> Voverriding_terminal_local_map)) > >> (gdb) xbacktrace > >> "key-binding" (0xffffd5c8) > >> "turn-on-undo-tree-mode" (0xffffd758) > >> "global-undo-tree-mode-enable-in-buffers" (0xffffd948) > >> "run-hooks" (0xffffd9e8) > >> "run-mode-hooks" (0xffffdbc0) > >> "minibuffer-inactive-mode" (0xffffdd40) > >> (gdb) > > > > In my debug build of Emacs 27.0.60 I get an assertion violation while > > dumping, which probably is already a sign of trouble. > > > > Daniel, any ideas? > > I haven't had a chance over the past few days to repro this problem, but I > hope to do so this weeekend. The messages about the assertion failure > *during* dumping do seem likely unrelated. The easiest way to debug this > particular crash is with rr. Run the original test as "rr record emacs > [args]", then run "rr replay". The latter will dump you in a GDB prompt. > Type "cont" and run the replay of Emacs until you get to the SIGSEGV. Run > "watch -l [expression]" to break out of execution whenever that value > changes, then run "reverse-cont" to run the replay *backwards* until you > get to the code that changed the variable with the bad value. > > ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-03-05 7:14 ` Eli Zaretskii @ 2020-03-09 2:15 ` Daniel Colascione 2020-03-09 3:26 ` Eli Zaretskii 0 siblings, 1 reply; 3+ messages in thread From: Daniel Colascione @ 2020-03-09 2:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: niwtrx, 38912 Sorry, haven't had a chance to look at it yet. I've been treating it as low-ish priority because pdumping outside loadup isn't supported yet. Is there some reason to expedite this work? > Ping! Any news in debugging this? > >> Date: Mon, 6 Jan 2020 09:10:20 -0800 >> From: "Daniel Colascione" <dancol@dancol.org> >> Cc: "NiwTinray" <niwtrx@icloud.com>, >> "Daniel Colascione" <dancol@dancol.org>, >> 38912@debbugs.gnu.org >> >> > [Please use "Reply All" to reply, so that the bug address is kept on >> > the CC list.] >> > >> >> From: NiwTinray <niwtrx@icloud.com> >> >> Date: Sun, 5 Jan 2020 13:25:07 +0800 >> >> >> >> > I cannot reproduce this from "emacs -Q" because 'use-package' is >> not a >> >> > known function. Can you show a recipe starting from "emacs -Q", >> >> > please? >> >> >> >> Here. I've attached a minimal script file that helps reproduce this >> bug. >> >> >> >> (require 'package) >> >> (package-initialize) >> >> (add-to-list 'package-archives >> >> '("melpa-stable" . "https://stable.melpa.org/packages/") >> t) >> >> (unless (package-installed-p 'evil) >> >> (package-refresh-contents) >> >> (package-install 'evil)) >> >> (require 'evil) >> >> (dump-emacs-portable "/tmp/test.pdmp") >> >> >> >> The script downloads the package "evil" from Melpa stable, load the >> evil >> >> package >> >> and dumps an image to /tmp/test.pdmp. >> >> >> >> > Also, does this happen if you add -Q to the Emacs invocation after >> >> > dumping? If not, there's more detail missing in your report: the >> >> > customizations in your init files. >> >> >> >> >> >> Sure. Please download this file, and run the command: >> >> >> >> emacs --batch -Q --script evil.el >> >> >> >> To see the bug happen, load the test.pdmp file: >> >> >> >> emacs -Q --dump-file /tmp/test.pdmp >> >> >> >> You should see a segmentation fault: >> >> >> >> [1] 23369 segmentation fault (core dumped) emacs -Q --dump-file >> >> /tmp/test.pdmp >> >> >> >> I run debugger inside src/.gdbinit using the command: >> >> >> >> gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp >> >> >> >> And logged backtrace. See my second attachment: >> >> >> >> (base) omnisky :: ~/emacs/src â¹emacs-27*⺠» gdb -x .gdbinit >> --args >> >> ./emacs --dump-file /tmp/test.pdmp >> >> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 >> >> Copyright (C) 2016 Free Software Foundation, Inc. >> >> License GPLv3+: GNU GPL version 3 or later >> >> <http://gnu.org/licenses/gpl.html> >> >> This is free software: you are free to change and redistribute it. >> >> There is NO WARRANTY, to the extent permitted by law. Type "show >> >> copying" >> >> and "show warranty" for details. >> >> This GDB was configured as "x86_64-linux-gnu". >> >> Type "show configuration" for configuration details. >> >> For bug reporting instructions, please see: >> >> <http://www.gnu.org/software/gdb/bugs/>. >> >> Find the GDB manual and other documentation resources online at: >> >> <http://www.gnu.org/software/gdb/documentation/>. >> >> For help, type "help". >> >> Type "apropos word" to search for commands related to "word"... >> >> Reading symbols from ./emacs...done. >> >> warning: File "/home/ntr/emacs/src/.gdbinit" auto-loading has been >> >> declined by your `auto-load safe-path' set to >> >> "$debugdir:$datadir/auto-load". >> >> To enable execution of this file add >> >> add-auto-load-safe-path /home/ntr/emacs/src/.gdbinit >> >> line to your configuration file "/home/ntr/.gdbinit". >> >> To completely disable this security protection add >> >> set auto-load safe-path / >> >> line to your configuration file "/home/ntr/.gdbinit". >> >> For more information about this security protection see the >> >> "Auto-loading safe path" section in the GDB manual. E.g., run from >> the >> >> shell: >> >> info "(gdb)Auto-loading safe path" >> >> SIGINT is used by the debugger. >> >> Are you sure you want to change it? (y or n) [answered Y; input not >> from >> >> terminal] >> >> Environment variable "DISPLAY" not defined. >> >> TERM = xterm-24bits >> >> Breakpoint 1 at 0x411df0: file emacs.c, line 370. >> >> Breakpoint 2 at 0x4bfe60: file xterm.c, line 10130. >> >> (gdb) r >> >> Starting program: /home/ntr/emacs/src/emacs --dump-file >> /tmp/test.pdmp >> >> /home/ntr/emacs/src/emacs: >> >> /raid_sdc/home/ntr/anaconda3/lib/libtiff.so.5: no version information >> >> available (required by /home/ntr/emacs/src/emacs) >> >> [Thread debugging using libthread_db enabled] >> >> Using host libthread_db library >> >> "/lib/x86_64-linux-gnu/libthread_db.so.1". >> >> >> >> Program received signal SIGSEGV, Segmentation fault. >> >> 0x00000000004f12d0 in Fcurrent_active_maps (olp=olp@entry=XIL(0x30), >> >> position=position@entry=XIL(0)) at keymap.c:1541 >> >> 1541 && NILP (KVAR (current_kboard, >> >> Voverriding_terminal_local_map)) >> >> (gdb) xbacktrace >> >> "key-binding" (0xffffd5c8) >> >> "turn-on-undo-tree-mode" (0xffffd758) >> >> "global-undo-tree-mode-enable-in-buffers" (0xffffd948) >> >> "run-hooks" (0xffffd9e8) >> >> "run-mode-hooks" (0xffffdbc0) >> >> "minibuffer-inactive-mode" (0xffffdd40) >> >> (gdb) >> > >> > In my debug build of Emacs 27.0.60 I get an assertion violation while >> > dumping, which probably is already a sign of trouble. >> > >> > Daniel, any ideas? >> >> I haven't had a chance over the past few days to repro this problem, but >> I >> hope to do so this weeekend. The messages about the assertion failure >> *during* dumping do seem likely unrelated. The easiest way to debug this >> particular crash is with rr. Run the original test as "rr record emacs >> [args]", then run "rr replay". The latter will dump you in a GDB prompt. >> Type "cont" and run the replay of Emacs until you get to the SIGSEGV. >> Run >> "watch -l [expression]" to break out of execution whenever that value >> changes, then run "reverse-cont" to run the replay *backwards* until you >> get to the code that changed the variable with the bad value. >> >> > ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded 2020-03-09 2:15 ` Daniel Colascione @ 2020-03-09 3:26 ` Eli Zaretskii 2021-06-24 16:30 ` bug#32503: 26.1; Byte-compiled functions don't hash consistently Lars Ingebrigtsen 0 siblings, 1 reply; 3+ messages in thread From: Eli Zaretskii @ 2020-03-09 3:26 UTC (permalink / raw) To: Daniel Colascione; +Cc: niwtrx, 38912 > Date: Sun, 8 Mar 2020 19:15:31 -0700 > From: "Daniel Colascione" <dancol@dancol.org> > Cc: "Daniel Colascione" <dancol@dancol.org>, > niwtrx@icloud.com, > 38912@debbugs.gnu.org > > Sorry, haven't had a chance to look at it yet. I've been treating it as > low-ish priority because pdumping outside loadup isn't supported yet. Is > there some reason to expedite this work? Not that I can see, no. I just wanted to be sure this isn't forgotten. Thanks. ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#32503: 26.1; Byte-compiled functions don't hash consistently 2020-03-09 3:26 ` Eli Zaretskii @ 2021-06-24 16:30 ` Lars Ingebrigtsen 0 siblings, 0 replies; 3+ messages in thread From: Lars Ingebrigtsen @ 2021-06-24 16:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 32503, niwtrx, Adam Porter, 38912 Eli Zaretskii <eliz@gnu.org> writes: >> Sorry, haven't had a chance to look at it yet. I've been treating it as >> low-ish priority because pdumping outside loadup isn't supported yet. Is >> there some reason to expedite this work? > > Not that I can see, no. I just wanted to be sure this isn't > forgotten. > > Thanks. This was a long thread, and I only skimmed it lightly. But I noticed that it was merged with this bug report: Adam Porter <adam@alphapapa.net> writes: > I noticed that byte-compiled functions don't hash consistently. Here's > an ECM from Noam Postavsky > <https://github.com/skeeto/emacs-memoize/pull/10#issuecomment-415066682>: > > (let ((obj1 (byte-compile (lambda (x) x))) > (obj2 (byte-compile (lambda (x) x)))) > (list (equal obj1 obj2) > (eq obj1 obj2) > (= (sxhash obj1) > (sxhash obj2)))) > ;=> (t nil nil) And this test case no longer fails in Emacs 28 (but it fails in Emacs 27). So is there more to be done in these merged bug reports? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-06-24 16:30 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-08-22 19:00 bug#32503: 26.1; Byte-compiled functions don't hash consistently Adam Porter 2018-08-23 1:42 ` Tom Tromey -- strict thread matches above, loose matches on Subject: below -- 2020-01-04 1:49 bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded NiwTinray via Bug reports for GNU Emacs, the Swiss army knife of text editors 2020-01-04 9:17 ` Eli Zaretskii [not found] ` <D1473DD8-48F8-4204-80B5-BE6396B8B668@icloud.com> 2020-01-05 18:45 ` Eli Zaretskii 2020-01-06 17:10 ` Daniel Colascione 2020-03-05 7:14 ` Eli Zaretskii 2020-03-09 2:15 ` Daniel Colascione 2020-03-09 3:26 ` Eli Zaretskii 2021-06-24 16:30 ` bug#32503: 26.1; Byte-compiled functions don't hash consistently Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).