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

[Rob Browning]

address@hidden writes:

> 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;
>     }

I believe so.  You're likely to be copying memory that doesn't belong
to ptr.

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

Yes.

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

If we're going to be using it for anything substantial, I tend to
think this would be *extremely* unwise.  Writing a good allocator is
*hard*.

If the performance is critical, then I suspect we should use the
system realloc if/when we can determine (via configure.in) that it's
reliable, and otherwise, we should be using more explicit means.
Using gnu libc's realloc certainly would have worked better in my
case.

Anyway from a quick glance, it looks like we're only using realloc for
strings, which you can easily determine the length of, and for
lt_caller_data which could be easily augmented to include a size
field.

So as one approach, we could just have str_realloc() and
realloc_caller_data(), and then these could use the system realloc
internally on platforms where that's considered beneficial.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD