bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47125: 28.0.50; pdumper assumes compile time page size remains valid


From: Daniel Colascione
Subject: bug#47125: 28.0.50; pdumper assumes compile time page size remains valid
Date: Sat, 13 Mar 2021 21:43:07 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

On 3/13/21 9:37 PM, Eli Zaretskii wrote:

From: Pip Cet <pipcet@gmail.com>
Date: Sat, 13 Mar 2021 21:38:16 +0000

I'm running Debian GNU/Linux (the Linux part is not provided by
Debian) on an Apple M1-based machine. This currently involves running
a kernel compiled with a 16 KB page size (the only fully functional
kernel is currently available as a binary as recompilation of the
alleged source fails to produce a fully working kernel).

The Debian-packaged Emacs version does not start. Compiling from
scratch works fine.

After some investigation, this is because pdumper assumes that an
address aligned according to the page size at build time is
sufficiently aligned for mmap to work with the MAP_FIXED flag, when it
comes to loading the dump. That's not true because the Debian Emacs
was apparently built with a 4 KB page size, so it will not run on a
system with a 16 KB page size.

I've confirmed that I get the same error on current master if I modify
getpagesize to return 4096 rather than the correct value.

I think it would be best to handle this case gracefully, and I thought
pdumper already did that, but it appears to simply fail.

There are good reasons for increasing the page size, so this is likely
to happen more often and on other architectures with varying page
sizes.
CC'ing Daniel, in case he has comments and/or suggestions.

We should modify this function to do what the doc comment says then. :-) I'm not sure if there's any reliable way to know what the worst case allocation granularity actually is: a quick grep through /usr/include didn't turn up anything. Maybe we should just use a minimum of 16kB here? It's not as if we'd be wasting a ton of RAM doing so.

/* Worst-case allocation granularity on any system that might load
   this dump.  */
static int
dump_get_page_size (void)
{
#if defined (WINDOWSNT) || defined (CYGWIN)
  return 64 * 1024;  /* Worst-case allocation granularity.  */
#else
  return getpagesize ();
#endif
}






reply via email to

[Prev in Thread] Current Thread [Next in Thread]