kern/85468: Memory leak within libpthread
dan at obluda.cz
Tue Aug 30 09:30:17 GMT 2005
>Synopsis: Memory leak within libpthread
>Arrival-Date: Tue Aug 30 09:30:15 GMT 2005
>Originator: Dan Lukes
>Release: FreeBSD 6.0-BETA3 i386
System: FreeBSD i386
When _tcb_ctor on 2373 pass but calloc on line 2375 failed then memory leak
occur (thread->tcb not destroyed properly)
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.
*) 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 ...
More information about the freebsd-bugs