[Top][All Lists]

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

Re: Preview: portable dumper

From: Robert Pluim
Subject: Re: Preview: portable dumper
Date: Thu, 15 Feb 2018 17:24:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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).


reply via email to

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