From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#47125: 28.0.50; pdumper assumes compile time page size remains valid Date: Sat, 13 Mar 2021 21:43:07 -0800 Message-ID: <90eb70a9-e482-3c08-9f14-8b813bdf0042@dancol.org> References: <83r1kigut8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40291"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 Cc: 47125@debbugs.gnu.org To: Eli Zaretskii , Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 14 06:44:33 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lLJYG-000ALk-Mz for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Mar 2021 06:44:33 +0100 Original-Received: from localhost ([::1]:53524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lLJYF-0002la-3x for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Mar 2021 00:44:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41318) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lLJXm-0002lP-Jl for bug-gnu-emacs@gnu.org; Sun, 14 Mar 2021 00:44:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49490) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lLJXm-0007qf-C6 for bug-gnu-emacs@gnu.org; Sun, 14 Mar 2021 00:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lLJXm-0005dI-9z for bug-gnu-emacs@gnu.org; Sun, 14 Mar 2021 00:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Mar 2021 05:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47125 X-GNU-PR-Package: emacs Original-Received: via spool by 47125-submit@debbugs.gnu.org id=B47125.161570059221580 (code B ref 47125); Sun, 14 Mar 2021 05:44:02 +0000 Original-Received: (at 47125) by debbugs.gnu.org; 14 Mar 2021 05:43:12 +0000 Original-Received: from localhost ([127.0.0.1]:32803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLJWy-0005bx-CD for submit@debbugs.gnu.org; Sun, 14 Mar 2021 00:43:12 -0500 Original-Received: from dancol.org ([96.126.100.184]:34818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLJWw-0005bl-GB for 47125@debbugs.gnu.org; Sun, 14 Mar 2021 00:43:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ifSFlk7dqBsbhLz2hCl4BCSXy0CHQHW34M4zYW385dk=; b=QKl50hW2PKm6LRbfxs1TxgMu28 gSKIBXUwPg6j0GzWSupjdyAWRny39aZGZS4ao43y+GJjJ16Ksi58l/phCQzrSYt/9IMqpOzQX3ouz yo/VXIZTh2CBUrLneVXCUNYV1lrn3f5KHv0c5DyYZrE+QJvgssa1VqyeCN0bl81WeCKyRjKSC06oC m0FEEN6Fm4Uq6H0AmuSJhzgxtONg8MuJWRtHW/mprM8x92ojtevVG+847I4Pvht2ybjK7pycSToyO Ftsm6ZQg++HuD5k7LrHQve2w4KZPIIrd9oxHIbPfcgdOBnEmIO7/GU0ZHPPyWOCmS7JMRgMEDbfn+ mLMIcNtg==; Original-Received: from [2604:4080:1321:8090:308c:1c2:a8b0:a941] (port=46136) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lLJWu-0003Kh-Ph; Sat, 13 Mar 2021 21:43:08 -0800 In-Reply-To: <83r1kigut8.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:202327 Archived-At: On 3/13/21 9:37 PM, Eli Zaretskii wrote: >> From: Pip Cet >> 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 }