bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded

[Daniel Colascione]

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.
>>
>>
>