[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/51654: wrong ps_strings breaks emacs20
The following reply was made to PR kern/51654; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
Subject: Re: kern/51654: wrong ps_strings breaks emacs20
Date: Sat, 26 Nov 2016 06:20:43 +0000
On Sat, Nov 26, 2016 at 06:15:00AM +0000, David Holland wrote:
> > The address space layout changed. ps_strings is placed at the very top,
> > without PAX it is at a fixed address.
> Turning off aslr with paxctl has no effect.
I take it back: making sure that emacs is dumped from a temacs with
aslr disabled fixes the problem.
But I don't follow why. Also, this doesn't explain why my preexisting
emacs binary (which was built long before we started mucking with aslr
this year) doesn't work and fails in the same way.
Or did the default non-randomized layout also change, and by the same
unclear mechanism thereby cause things to stop working?
> > > I haven't the slightest idea why this happens only with emacs but I
> > > imagine it's a consequence of the emacs dump/undump mechanism somehow.
> > Combine this with the changed MAXUSER address and now certain cached
> > locations no longer match.
> Cached in what? The value for __ps_strings is provided by the kernel
> to crt0 and propagates to _libc_init (and causes it to croak) before
> anything in emacs gets control.
Even if the prior value is saved when undumped, that should be
overwritten by a new value from the current execution, no?
David A. Holland
Main Index |
Thread Index |