comment from a user...

Julian Elischer julian at freebsd.org
Mon Jun 13 08:15:41 UTC 2016


On 8/06/2016 12:44 PM, Konstantin Belousov wrote:
> 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.

yes I told him as much.. also that the 'abort' makes it almost "not an 
error"  no matter how much memory is leaked as 'abort' is not supposed 
to be recoverable
>



More information about the freebsd-threads mailing list