[Top][All Lists]

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

Re: Preview: portable dumper

From: Daniel Colascione
Subject: Re: Preview: portable dumper
Date: Wed, 14 Feb 2018 09:49:49 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

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,

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 


   #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, 
       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.

reply via email to

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