From owner-freebsd-bugs@FreeBSD.ORG Tue Aug 30 09:30:17 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67CD616A420 for ; Tue, 30 Aug 2005 09:30:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFAAE43D49 for ; Tue, 30 Aug 2005 09:30:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j7U9UFmQ000470 for ; Tue, 30 Aug 2005 09:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j7U9UFjX000469; Tue, 30 Aug 2005 09:30:15 GMT (envelope-from gnats) Resent-Date: Tue, 30 Aug 2005 09:30:15 GMT Resent-Message-Id: <200508300930.j7U9UFjX000469@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Dan Lukes Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01DA316A41F; Tue, 30 Aug 2005 09:27:30 +0000 (GMT) (envelope-from dan@kulesh.obluda.cz) Received: from kulesh.obluda.cz (kulesh.obluda.cz [193.179.22.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id C158A43D48; Tue, 30 Aug 2005 09:27:28 +0000 (GMT) (envelope-from dan@kulesh.obluda.cz) Received: from kulesh.obluda.cz (localhost.eunet.cz [127.0.0.1]) by kulesh.obluda.cz (8.13.4/8.13.4) with ESMTP id j7U9RPm0009775; Tue, 30 Aug 2005 11:27:25 +0200 (CEST) (envelope-from dan@kulesh.obluda.cz) Received: (from dan@localhost) by kulesh.obluda.cz (8.13.4/8.13.1/Submit) id j7U9RPQC009774; Tue, 30 Aug 2005 11:27:25 +0200 (CEST) (envelope-from dan) Message-Id: <200508300927.j7U9RPQC009774@kulesh.obluda.cz> Date: Tue, 30 Aug 2005 11:27:25 +0200 (CEST) From: Dan Lukes To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: deischen@FreeBSD.org Subject: kern/85468: Memory leak within libpthread X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan Lukes List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 09:30:17 -0000 >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: