Re: dynamically allocated memory




Gordon Burditt wrote:
> >> > Can i replace gnu libc malloc without recompiling libc?
> >>
> >> There is no one, right, portable way to do it except to '#define malloc
> >> mymalloc' (or never call 'malloc') and compile all your code that way. Many
> >> libraries have their own way to replace the memory allocation functions. For
> >> example, OpenSSL has CRYPTO_set_mem_functions. There is, of course, also
> >> non-portable linker magic.
> >
> >I'm surprised to read that.
> >
> >Is not placing your own object with malloc/free before libc in the
> >linker object list the portable way to do this at link time? Or using
> >LD_PRELOAD at run time?
>
> You are not guaranteed that the linker can drag in individual symbols
> separately from libc (especially if it's static-linked). You might
> end up with malloc() and free() from your own object, and one object
> module from libc.a containing exit(), malloc(), free(), and fflush().
> Since you've got TWO malloc()s and TWO free()s, the link dies on a
> multiply defined symbol.

This is false for Linux at least. All imported symbols no matter how
objects were linked are subject to dynamic linking. So, there is no way
a process accidentally uses two different malloc/free, all the
references will be resolved by dl.so to the only implementation.

> This is less likely to be a problem with dynamic-linked libraries.
> However, with dynamic-linked libraries, you are likely to have the
> problem that fopen() calls the malloc() in the libc library, not
> the one you supplied.

This is also wrong since malloc is an exported symbol, rather than
private.

Refer to http://people.redhat.com/drepper/dsohowto.pdf

.



Relevant Pages

  • Re: ZLib double free bug: Windows NT potentially unaffected
    ... I've been researching this bug since I heard that ssh passes packets to zlib ... Double free vulnerabilities are primarily an issue for malloc implementations ... how exploitation of this error works entitled: ... Also as noted above some malloc libraries have explicit protection mechanisms ...
    (Bugtraq)
  • Re: So I want to exhaust a lot of memory
    ... But if there's a good reason for malloc() et al. ... at this point I would still prefer to check errno ...   standard_realloc, ...
    (comp.lang.c)
  • Re: dynamically allocated memory
    ... >>linker object list the portable way to do this at link time? ... > separately from libc. ... > end up with malloc() and freefrom your own object, ... > This is less likely to be a problem with dynamic-linked libraries. ...
    (comp.unix.programmer)
  • Re: So I want to exhaust a lot of memory
    ... malloc and friends' influence on the standard library or 3rd party ... at this point I would still prefer to check errno ...
    (comp.lang.c)
  • Re: Help with Enter and Leave Instructions
    ... to manage the chunks ourselves. ... The "normal" way to do this would be with the C library's "malloc". ... Unix, saying that Unix has a DOS-style interface gets things ... libraries, but I'd still have an inclination to keep everything "in house". ...
    (alt.lang.asm)