Re: Preview: portable dumper

[Robert Pluim]

Daniel Colascione <address@hidden> writes:

> On 02/14/2018 11:07 AM, Eli Zaretskii wrote:
>>> Cc: address@hidden
>>> From: Daniel Colascione <address@hidden>
>>> Date: Wed, 14 Feb 2018 09:49:49 -0800
>>>
>>>>     #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.
>>
>> You are talking about what enlarge_buffer_text does?  IOW, this:
>
> It should be fixed now. Give it a shot.

I'm not sure if this was meant for me as well. In any case, I just
pulled and rebuilt, and everything seems to be working well as of
commit 9484bb3ab8e39add474400e5982802b61c56eb3a (I'm using it to write
this message).

Robert