[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: Rob Browning
Subject: Re: ltdl.c thinks it's psychic (another SEGFAULT bug).
Date: Wed, 07 Nov 2001 00:39:32 -0600
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1

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?


> 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

If the performance is critical, then I suspect we should use the
system realloc if/when we can determine (via 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

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

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,, and
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

reply via email to

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