Date: Mon, 13 Jun 2016 16:15:23 +0800 From: Julian Elischer <julian@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-threads@freebsd.org Subject: Re: comment from a user... Message-ID: <6d91afd1-05a5-fa4d-c470-5cf23ddfb63a@freebsd.org> In-Reply-To: <20160608044433.GW38613@kib.kiev.ua> References: <86df5edc-87ce-89ef-7a30-23e068a6efcc@freebsd.org> <20160608044433.GW38613@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6d91afd1-05a5-fa4d-c470-5cf23ddfb63a>