comment from a user...

[Konstantin Belousov]

On Wed, Jun 08, 2016 at 12:32:18PM +0800, Julian Elischer wrote:
> I got the following from a user...
> He's (forced to) use FreeBSD 8
> Is this still an issue? and does anyone have thoughts?
> 
> -------------------------
> 
> Hi Julian,
> I have a set of code with a fairly strong unit test framework. This 
> framework works on Windows (cygwin) and Linux amongst other 
> platforms.  While running tests I always verify all allocated memory 
> is freed for good hygiene.
> 
> I've been running a test which has a printf in it and the following stack:
> #3  0x0000000000405219 in calloc (count=1, size=80) at testrunner.c:642
> #4  0x0000000806bd1ce4 in pthread_mutexattr_init () from /lib/libthr.so.3
> #5  0x0000000806bd1f91 in pthread_mutex_getyieldloops_np () from 
> /lib/libthr.so.3
> #6  0x0000000806bd2b81 in pthread_mutex_lock () from /lib/libthr.so.3
> #7  0x0000000806dcda13 in abort () from /lib/libc.so.7
> #8  0x0000000806dcdab3 in abort () from /lib/libc.so.7
> #9  0x0000000806dc91b9 in getenv () from /lib/libc.so.7
> #10 0x0000000806dc37ae in open () from /lib/libc.so.7
> #11 0x0000000806dc50ca in vfprintf () from /lib/libc.so.7
> #12 0x0000000806db10fa in printf () from /lib/libc.so.7
> 
> 
> This calloc'd memory never gets freed and forces my unit tests to fail.
> 
> I know this is an extremely old version of FreeBSD, but I figured I'd 
> let you know so that perhaps somebody, somewhere, might be interested 
> in such things and get a hold of the stack trace.

The backtrace is not useful, since without debugging information,
closest symbols are matched, and we do not see real function calls.

That said, our statically allocated locks allocate memory on the first
touch. And since locks are statically allocated, the memory is never freed.
I do not see anything wrong with that.