[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33174: 27.0.50; Dump fails on GNU/Linux ppc64le
From: |
Paul Eggert |
Subject: |
bug#33174: 27.0.50; Dump fails on GNU/Linux ppc64le |
Date: |
Mon, 29 Oct 2018 19:16:41 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
On 10/29/18 6:28 PM, Thomas Fitzsimmons wrote:
I guess I could experiment with adding the PaX patches to my kernel so
that XATTR_PAX would take effect, but I'm surprised Emacs can't complete
the bootstrap step when the kernel is in a default configuration.
You're right, the XATTR_PAX stuff is likely a red herring. Emacs should
be able to bootstrap without it by using the reexec trick, and
bootstrapping does work on Fedora 28 (kernel 4.18.16-200.fc28.x86_64)
without XATTR_PAX being used.
The main issue now, as I see it, is why Emacs is crashing on re-exec.
That is, on my system after I run 'make SETFATTR=: bootstrap-emacs' to
simulate a system without XATTR_PAX, the command
strace -o /tmp/tr ./temacs --batch --load loadup bootstrap
generates the syscalls:
...
personality(0xffffffff) = 0 (PER_LINUX)
personality(PER_LINUX|ADDR_NO_RANDOMIZE) = 0 (PER_LINUX)
personality(0xffffffff) = 0x40000
(PER_LINUX|ADDR_NO_RANDOMIZE)
execve("./temacs", ["./temacs", "--batch", "--load", "loadup",
"bootstrap"], 0x852ee10 /* 73 vars */) = 0
...
whereas on your system Emacs is crashing instead of issuing the execve.
I suspect that something like the following may help you debug:
$ cd src
$ make clean
$ make CFLAGS='-g3 -O0' SETFATTR=: temacs
$ gdb temacs
(gdb) set disable-randomization off
(gdb) b personality
(gdb) r --batch --load loadup bootstrap
and then poke around to see what 'personality' is returning and whether
'disable_address_randomization' succeeds and how 'execve' is being
called. I guess on your host, personality (0xffffffff) returns 0, then
personality (0x40000) returns 0, then personality (0xffffffff) returns
0x40000, then disable_address_randomization () returns true, but it
would be helpful to check this. The next thing should be that getenv
("EMACS_HEAP_EXEC") returns NULL; is that what actually happens? And
then xputenv ("EMACS_HEAP_EXEC=true") should work without crashing; is
that right? And is execvp being called and with what arguments? That
sort of thing.
- bug#33174: 27.0.50; Dump fails on GNU/Linux ppc64le, Thomas Fitzsimmons, 2018/10/27
- bug#33174: 27.0.50; Dump fails on GNU/Linux ppc64le, Thomas Fitzsimmons, 2018/10/28
- bug#33174: 27.0.50; Dump fails on GNU/Linux ppc64le, Paul Eggert, 2018/10/29
- bug#33174: 27.0.50; Dump fails on GNU/Linux ppc64le, Thomas Fitzsimmons, 2018/10/29
- bug#33174: 27.0.50; Dump fails on GNU/Linux ppc64le, Paul Eggert, 2018/10/30
- bug#33174: 27.0.50; Dump fails on GNU/Linux ppc64le, Thomas Fitzsimmons, 2018/10/30