emacs-devel
[Top][All Lists]
Advanced

[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;
    else
      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);
  #else
    p = xrealloc (b->text->beg, new_nbytes);
  #endif

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]