[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 11:26:37 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

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.

reply via email to

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