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>