From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Wed, 14 Feb 2018 10:11:36 -0800 Message-ID: <9292ada2-6322-2a8a-7042-ebc610044300@dancol.org> References: <1775923222.898447.1518559575706@mail.libero.it> <83inb0xkfx.fsf@gnu.org> <87o9krdftc.fsf@gmail.com> <83a7wby1x4.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1518631838 20989 195.159.176.226 (14 Feb 2018 18:10:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Feb 2018 18:10:38 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii , Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 14 19:10:34 2018 Return-path: Envelope-to: ged-emacs-devel@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 1em1Vd-0004SY-NI for ged-emacs-devel@m.gmane.org; Wed, 14 Feb 2018 19:10:22 +0100 Original-Received: from localhost ([::1]:45978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1em1Xf-0002mI-JW for ged-emacs-devel@m.gmane.org; Wed, 14 Feb 2018 13:12:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1em1X0-0002lZ-NS for emacs-devel@gnu.org; Wed, 14 Feb 2018 13:11:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1em1Wy-0004ux-JY for emacs-devel@gnu.org; Wed, 14 Feb 2018 13:11:46 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59898) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1em1Wy-0004uG-4z; Wed, 14 Feb 2018 13:11:44 -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:References:Cc:To:From:Subject; bh=80NRkxYk5MppoF7fFY9R/2U0PpVa2Pm5DcAzMOnKR7Q=; b=o1YdtloAhIB2kpmrN8wzHtjBCX41XcMeqRVeW/Mc6QbDRBbsZykNnobDq3Kbvdd8RaLghwUhW7QfLXLsDdw/8a71z/S/ngobvyXgJlgVpAZrc38KnF/4J+i9lP4Tr3zcFvOsrjar0+JnyMlT/IXIff9Aw3Xx2vISQPaXn6ousN9yCoYwYmxBEBOv4s+njvMXwmPY4kVtNXIBtHVP/mde83suXDu+cHQ+Ds2BAPGa7cnpHtHSuNRHV8KbV7YdlIGIXCHvr/Pbd+s5zPPtpv2Y5UAW85meYuJeSOJoP+979XQ9IFGPoMw+14I59vw4fj797ZpSH8tKj80cGD3eJ4bXkw==; Original-Received: from [2604:4080:1321:8ab0:5c3b:80f7:5474:b86b] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1em1Ww-0002vW-SA; Wed, 14 Feb 2018 10:11:42 -0800 In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222744 Archived-At: On 02/14/2018 09:49 AM, Daniel Colascione wrote: > On 02/14/2018 08:24 AM, Eli Zaretskii wrote: >>> From: Robert Pluim >>> Date: Wed, 14 Feb 2018 11:30:07 +0100 >>> >>>>> What should we look for? >>>> >>>> The usual stuff, I think: does it build, does it work as expected, >>>> etc. >>> >>> You mean like: >> >> Yes, like that. >> >> I see something slightly different on MS-Windows (in a build with >> "--enable-checking"), but maybe similar enough to be explained by the >> same problem: >> >>         ELC      ../lisp/composite.elc >>       load_dump completed in 46.005 milliseconds >> >>       insdel.c:1937: Emacs fatal error: assertion failed: >> !pdumper_object_p (BEG_ADDR) >> >> Backtrace: >> >>    #0  0x762c3227 in KERNELBASE!DebugBreak () >>       from C:\Windows\syswow64\KernelBase.dll >>    #1  0x0131940d in emacs_abort () at w32fns.c:10874 >>    #2  0x01152dea in terminate_due_to_signal (sig=22, >> backtrace_limit=2147483647) >>        at emacs.c:388 >>    #3  0x01206274 in die ( >>        msg=0x16ce7d2 "!pdumper_object_p >> (BEG_ADDR)", >>        file=0x16ce674 "insdel.c", line=1937) >>        at alloc.c:7789 >>    #4  0x011acb8b in prepare_to_modify_buffer_1 (start=1, end=1, >>        preserve_ptr=0x0) at insdel.c:1937 > > It's weird that we're failing there. If we're looking at a buffer with > dumped contents, we set b->text->beg to NULL, then use the normal > buffer-allocation procedure (whichever we're compiled to use) to > allocate memory for the contents. How can the resulting address ever be > equal to what we started with? Neither mmap_realloc nor r_re_alloc nor > xrealloc should ever reuse the address. Oh, I think I know what's going on. We must be reallocating from the discardable region, which we unmapped on startup, but pdumper_object_p still thinks that this memory (which the allocator can legitimately use for some other purpose) is part of the dump (since pdumper_object_p uses a simple range check) and malfunctions. I'll add a patch to keep this address space reserved. I just added the actually-discard-the-discardable region code, so I'm not surprised it broke. On my machine, we happen to never reuse that address space.