Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Aug 2005 11:27:25 +0200 (CEST)
From:      Dan Lukes <dan@obluda.cz>
To:        FreeBSD-gnats-submit@FreeBSD.org
Cc:        deischen@FreeBSD.org
Subject:   kern/85468: Memory leak within libpthread
Message-ID:  <200508300927.j7U9RPQC009774@kulesh.obluda.cz>
Resent-Message-ID: <200508300930.j7U9UFjX000469@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         85468
>Category:       kern
>Synopsis:       Memory leak within libpthread
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 30 09:30:15 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Dan Lukes
>Release:        FreeBSD 6.0-BETA3 i386
>Organization:
Obludarium
>Environment:
System: FreeBSD i386
thread/thr_kern.c 1.117

>Description:
thread/thr_kern.c 1.117

When _tcb_ctor on 2373 pass but calloc on line 2375 failed then memory leak
occur (thread->tcb not destroyed properly)

>How-To-Repeat:
	N/A
>Fix:

	I submit no patch here. See patch for PR 83457

	The note to commiter (I assume this PR will be assigned to Daniel
Eischen, the commiter of PR 83457):

	In the PR 83457 i explicitly warn the thread->tcb must be properly 
destroyed in the case of calloc failures.

	It's simple - when _tcb_ctor() has been called and passed, then
deinitialisation via calling _tcb_dtor() is mandatory. Skipping this step
is safe under NO condition (at least, you can't count future changes 
within _tcb_ctor() code)

	I spent my time to analyze the code to be correct within wide range
of edge conditions before submitting the PR 83457 (*) - then I suggest to 
rearrange code to swap initialization order to avoid tcb deinitialization problem.

	I fully respect commiter's power to deny my suggestion. I don't push 
anybody to commit *my* code. Be free to throw out the energy I spent 
to code analysis related to creating a PR's for any reason, including 
the "I don't understand rearranged code" or "I hate gotos" reasons. 
But then you should spent sufficient  amount of *your* time do your own 
analysis of code before you create your-own-way patch. 

	I don't want to be misunderstanded - it's not personal offence in
any way (please note, the english is not my natural language, so don't
overestimate my word selection and ordering).

	Thank you very much for working for FreeBSD project.

						Dan Lukes

 ==============

*) I has been security officer within financial institution - analysis of
the code created by our programmers to identify weak and bad code has been
part of my daily work. I can do the same job for FreeBSD, if someone interested.

Well, I know that nobody welcome someone's complaints "your code is weak or
wrong". Someone responsible (security officer ?) should decide if the FreeBSD 
project need (and can accept) this kind of help ...
>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508300927.j7U9RPQC009774>