[Top][All Lists]

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

Re: Preview: portable dumper

From: Eli Zaretskii
Subject: Re: Preview: portable dumper
Date: Wed, 14 Feb 2018 21:07:20 +0200

> 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:

    if (pdumper_object_p (old_beg))
      b->text->beg = NULL;
      old_beg = NULL;

  #if defined USE_MMAP_FOR_BUFFERS
    p = mmap_realloc ((void **) &b->text->beg, new_nbytes);
  #elif defined REL_ALLOC
    p = r_re_alloc ((void **) &b->text->beg, new_nbytes);
    p = xrealloc (b->text->beg, new_nbytes);

I will try to look around this when I have time, and see what I find.

reply via email to

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