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>