[Top][All Lists]

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

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

From: libtool
Subject: Re: ltdl.c thinks it's psychic (another SEGFAULT bug).
Date: Wed, 7 Nov 2001 00:09:23 -0600
User-agent: Mutt/1.2.5i

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?
      /* 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)

reply via email to

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