Date: Sat, 19 Sep 1998 16:04:12 -0500 From: Alex Nash <nash@mcs.net> To: chaos@ultra.net.au, current@FreeBSD.ORG Subject: Re: free() isn't threads safe! Message-ID: <19980919160412.G16974@pr.mcs.net> In-Reply-To: <Pine.BSF.4.02.9809200113170.9082-100000@chaotic.oz.org>; from Simon Coggins on Sun, Sep 20, 1998 at 01:18:00AM %2B1000 References: <Pine.BSF.4.02.9809200113170.9082-100000@chaotic.oz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 20, 1998 at 01:18:00AM +1000, Simon Coggins wrote:
> This is the code from lib/libc/stdlib/malloc.c
>
> void
> free(void *ptr)
> {
> malloc_func = " in free():"; <- isn't there a slim chance this can be
> changed before the thread is locked?
Right you are. In fact malloc() and realloc() had the same problem.
> THREAD_LOCK();
> if (malloc_active++) {
> wrtwarning("recursive call.\n");
> malloc_active--;
> return; <--------- Shouldn't the thread be unlocked before returning?
Yes.
> Wouldn't something like:
>
> void
> free(void *ptr)
> {
> THREAD_LOCK();
> malloc_func = " in free():";
> if (malloc_active++) {
> wrtwarning("recursive call.\n");
> malloc_active--;
> THREAD_UNLOCK();
> return;
> }
[...]
> Be more sensable?
I committed a slightly different fix to -current (I'll merge this back
into -stable later this weekend) using a single exit point from free().
Cue Terry to explain the advantages of single entry/single exit
functions...
Alex
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980919160412.G16974>