Re: Asymmetry between __libc_memalign() and free() in dl-tls.c ?

[Petter Reinholdtsen]

[Colin Smith, 2003-06-24]
> Dear glibc mavens,
>
> I'm working on an application developed under glibc-2.2.2.  When I run
> it with glibc-2.3.2 in its special "debug" mode, it reports a memory
> corruption error.  In debug mode, the app defines the symbols malloc(),
> free() etc.  In the malloc case, it calls __libc_malloc with in order to
> implement guard zones on either end of the requested memory buffer.
>
> I've tracked this down to sysdeps/generic/dl-tls.c: the thread manager
> allocates a buffer of memory with __libc_memalign(), but frees it with
> free.
>
> If only it would free the memory with __libc_free(), my app would be
> fine, since memory obtained/freed this way avoids the guard zone code. 
> Since the memory is being freed with free(), we think it must have been
> obtained with malloc, and when we don't see the magic pattern in the
> guard zones the app assumes memory has been trampled.
>
> Do you agree that it would be better if __libc_ calls were matched up
> here, or is there a subtlety I'm missing?

Sounds like a bug to me.  But I do not really know.  I'm not sure if
the glibc maintainers read this list.  You might want to submit your
bug to the glibc bugzilla, available from
<URL:http://sources.redhat.com/bugzilla/>.