Re: ltdl.c thinks it's psychic (another SEGFAULT bug).

[libtool]

On Tue, Nov 06, 2001 at 08:30:15PM -0600, Rob Browning wrote:
> I finally found one of the gnucash segfaults I've been chasing for a
> long time :<   I turned my attention fully to libtool after seeing
> stefan's last segfault warning.
> 
> The simple summary: you can't trivially replace realloc unless you
> also control malloc.  Without controlling malloc, how could realloc
> possibly know how much data to copy from the source?
> 
> To fix this, ltdl.c needs to quit providing its own replacement for
> realloc, or it needs to also provide a replacement malloc so that it
> will know the size of the srcptr.
> 
> The current ltdl code uses the size of the destination (i.e. the
> realloc size arg) to determine how much data to copy.  This means that
> it's often copying random parts of the heap -- and sometimes the OS is
> watching...

So the following is bogus?
  else
    {
      /* Allocate a new block, copy and free the old block.  */
      lt_ptr mem = lt_dlmalloc (size);

      if (mem)
        {
          memcpy (mem, ptr, size);
          lt_dlfree (ptr);
        }

      /* Note that the contents of PTR are not damaged if there is
         insufficient memory to realloc.  */
      return mem;
    }

Reading your synopsis above, I agree. How can the memcpy work if ptr
isn't guaranteed to be size bytes long? Have you tracked the segfault
in GDB to the code above? BTW, I don't think ltdl works on HP-UX
(segfault) and some versions of Tru64 UNIX but I haven't had the time
to follow up on why.

So, if we replace malloc, we then need a table of pointers and their
size. Worth it?

-- 
albert chin (address@hidden)