Re: Preview: portable dumper

[Daniel Colascione]

On 02/14/2018 09:49 AM, Daniel Colascione wrote:
> On 02/14/2018 08:24 AM, Eli Zaretskii wrote:
> > > From: Robert Pluim <address@hidden>
> > > 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 <DEFAULT_REHASH_SIZE+354> "!pdumper_object_p 
> > (BEG_ADDR)",
> >        file=0x16ce674 <DEFAULT_REHASH_SIZE+4> "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.