From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Thomas Fitzsimmons Newsgroups: gmane.emacs.bugs Subject: bug#33174: 27.0.50; Dump fails on GNU/Linux ppc64le Date: Tue, 30 Oct 2018 05:30:47 -0400 Message-ID: References: <39df62a1-58fb-0e5c-88a6-3eaae4e865d4@cs.ucla.edu> <9fbbce6a-ca72-e4e2-1456-49e146542896@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1540891449 14731 195.159.176.226 (30 Oct 2018 09:24:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 09:24:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33174@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 30 10:24:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHQFo-0003jt-6c for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Oct 2018 10:24:04 +0100 Original-Received: from localhost ([::1]:51770 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHQHu-00030b-4N for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Oct 2018 05:26:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHQHm-00030U-GS for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 05:26:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHQHi-0007BB-Ev for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 05:26:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49103) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHQHi-0007B7-8y for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 05:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gHQHi-0007kj-4V for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 05:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thomas Fitzsimmons Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Oct 2018 09:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33174 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33174-submit@debbugs.gnu.org id=B33174.154089151629746 (code B ref 33174); Tue, 30 Oct 2018 09:26:02 +0000 Original-Received: (at 33174) by debbugs.gnu.org; 30 Oct 2018 09:25:16 +0000 Original-Received: from localhost ([127.0.0.1]:53361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHQGy-0007ji-6R for submit@debbugs.gnu.org; Tue, 30 Oct 2018 05:25:16 -0400 Original-Received: from mail-it1-f175.google.com ([209.85.166.175]:50207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHQGx-0007jV-03 for 33174@debbugs.gnu.org; Tue, 30 Oct 2018 05:25:15 -0400 Original-Received: by mail-it1-f175.google.com with SMTP id k206-v6so12909385ite.0 for <33174@debbugs.gnu.org>; Tue, 30 Oct 2018 02:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fitzsim-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=XYs+aaR1f6wMzRW4dr9xnpYpXfH/tLQ9ZQF8EZ5K9fU=; b=Zmy7+1+/3aptWHmrsxevcw/ej09aqVKInpjGzgph0odm9l0PxPTxVu5p5i7lu0Zvdz 8HnZIbYs3+gskojPBxuxzBee2WYnDVgck/GYYuBE47z7YKHd5sg1l4QXpWa45iF1fppj R6nQBMBnXiXQ/ElVqY4S3sCGigHwk6OEWo5/Ml+bGTlTBvRFMfIwhBcNbZ616/WHa8NJ Hxwgj2k/I0LSoMf9tu4wTIZDnwxa8uSAa+NFsXq8mcv0maTyafIVRFKVn1EMkOWAR6NA wk3dWQAcwciwKOyeB5pgw3qi0c7nyvjsMVxgFux80rQVpt0XkKrmRub/uvOxLOz2vzNn aicQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=XYs+aaR1f6wMzRW4dr9xnpYpXfH/tLQ9ZQF8EZ5K9fU=; b=G2ThV+9egZwsrITQsbgGZpZmQvUPDh5+fV9+Y9Hzl1Ja06GkOcFYFrocwJPRNlnm5p dmBMFOqB9DjWSJwnnrftmC2gG6Aw0Jo52Z4g1X1EZW2zROoa4YhTFX4X9n2JS3TpDJf1 M4ZE0c1BD3D69Vp4oOwZMqCCHWesdy6HtBJ1n4vQiMNfv+zRuU1+SmkY8Qjqe91eTYIY HFrg2hDodNO71aovzoBID2P8AcE0WvcHOT14yESRp5Y9HyZJW9VQgOr3+rFr/R6I0LfY bRbFy7GkO/dvQryTyKSo9+Esjq8is1nJwNfjH7mFNjT4whlit57CxAcwwh+Q70byfjE3 prCw== X-Gm-Message-State: AGRZ1gJ6vuAiXcELJ8y6d8DbPPCBC9UL56+W/S7GWcRqS4zyCdSyXYmZ nWBRpZZD5D3w7x0ECHBzRAZ0tLD35FLPlh09 X-Google-Smtp-Source: AJdET5clssPNa8hy48q1LTplHG1x+6TrfhQtSqK7iuzyqHlZfJe0Q9uQA3jX8ap6WKvFlD7sZ5lJqA== X-Received: by 2002:a02:3f19:: with SMTP id d25-v6mr337885jaa.101.1540891508969; Tue, 30 Oct 2018 02:25:08 -0700 (PDT) Original-Received: from localhost.localdomain (69-165-165-189.dsl.teksavvy.com. [69.165.165.189]) by smtp.gmail.com with ESMTPSA id z9-v6sm6732511iom.12.2018.10.30.02.25.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 02:25:07 -0700 (PDT) In-Reply-To: <9fbbce6a-ca72-e4e2-1456-49e146542896@cs.ucla.edu> (Paul Eggert's message of "Mon, 29 Oct 2018 22:58:19 -0700") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151818 Archived-At: Paul Eggert writes: > Thomas Fitzsimmons wrote: >> BTW, let me know if you don't think it's useful to debug this further. >> I'm OK just disabling randomization when I build Emacs for the time >> being and waiting until the portable dumper work lands, but I'm happy to >> continue if you think it will lead to a general fix. > > It's not clear when the portable dumper will land; it might not ever > land, unfortunately. So I would like to work on bug#33174 a bit > longer, if only so that we can put something intelligible into the > PROBLEMS file. OK. >> It seems like it's crashing when trying to memcpy over the BSS area, on >> this line in unexelf.c (see below): > > By the time the memcpy is run the damage has already been done: the > memory layout is messed up and we can't fix that simply by passing > different arguments to memcpy. We have to prevent the memory layout > from being messed up in the first place by disabling undesirable > address space layout randomization and doing this very early in > execution. Ah, OK, so the goal is to programmatically do something similar to echo'ing to randomize_va_space, but just for the temacs process. > The key question for me is in this set of system calls: > >> 58215 personality(0xffffffff) = 0 (PER_LINUX) >> 58215 personality(PER_LINUX|ADDR_NO_RANDOMIZE) = 0 (PER_LINUX) >> 58215 personality(0xffffffff) = 0x40000 (PER_LINUX|ADDR_NO_RANDOMIZE) >> 58215 brk(NULL) = 0x27070000 >> 58215 dup2(0, 0) = 0 >> 58215 dup2(1, 1) = 1 >> 58215 dup2(2, 2) = 2 > > Surely the call to disable_address_randomization () must have returned > true, but can you verify that, either via GDB or (shudder) by > inserting print statements? (I sorted out glibc source code and debug symbols so they'll be accurate now). Yes, disable_address_randomization returns true: [...] (gdb) finish Run till exit from #0 0x0000000010136d9c in disable_address_randomization () at sysdep.c:165 0x0000000010016c94 in main (argc=, argv=0x7fffd4430178) at emacs.c:710 710 if (disable_aslr && disable_address_randomization () Value returned is $1 = true [...] > Also, the call from 'main' to getenv ("EMACS_HEAP_EXEC") must have > returned NULL. Can you also verify this? (gdb) c Continuing. Breakpoint 4, 0x00007fff9dc1ef98 in __GI_getenv (name=0x10274ce8 "EMACS_HEAP_EXEC") at getenv.c:34 34 { (gdb) finish Run till exit from #0 0x00007fff9dc1ef98 in __GI_getenv (name=0x10274ce8 "EMACS_HEAP_EXEC") at getenv.c:34 0x0000000010017870 in main (argc=, argv=0x7ffff4883248) at emacs.c:711 711 && !getenv ("EMACS_HEAP_EXEC")) Value returned is $2 = 0x7ffff488fe49 "true" Actually, EMACS_HEAP_EXEC is true! If I unset it, then the bootstrap works with and without "Fix bootstrap infloop in GNU/Linux alpha" applied. I'm building Emacs inside Emacs via M-x shell. "EMACS_HEAP_EXEC=true" is in process-environment. Given that I'm also running EXWM, no matter what build shell I start up, even an xterm, EMACS_HEAP_EXEC is set to "true" in the environment. Ah, by running the "outer" Emacs via a serial console (i.e., not from within Emacs, and starting with EMACS_HEAP_EXEC unset in the environment), I think I see what happened. Because of the ifdef just above the randomization disablement code: # ifdef __PPC64__ bool disable_aslr = true; # else bool disable_aslr = dumping; # endif randomization is unconditionally disabled on PPC64, and so EMACS_HEAP_EXEC is unconditionally set to true in the outer build Emacs's initial-environment. With "Fix bootstrap infloop in GNU/Linux alpha" applied, building Emacs within Emacs on PPC64 will no longer work because the re-exec will be skipped during bootstrap. Maybe can you try building Emacs within Emacs on one of those CentOS machines to confirm? Thanks, Thomas