289709 - Memory Leak: _PR_MD_INIT_THREAD (w95thred.c): CreateSemaphore - never freed.

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Itay Perl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

In mozilla\nsprpub\pr\src\md\windows\w95thred.c:
Line 105: thread->md.blocked_sema = CreateSemaphore(NULL, 0, 1, NULL);
Created and never released.

recommendation: in mozilla\nsprpub\pr\src\threads\combined\pruthr.c:
Add line: CloseHandle(thread->md.blocked_sema);
to PR_DestroyThread (around line 343).

Reproducible: Always

Steps to Reproduce:




Leak detected with BoundsChecker 7.2.0

Comment 1

[Wan-Teh Chang]

That semaphore handle is closed in _PR_MD_CLEAN_THREAD,
which is called by _PR_MD_EXIT_THREAD.

We call _PR_MD_EXIT_THREAD before calling _PR_DestroyThread,
so this is already done.

What happens is most likely that the application you
ran BoundsChecker on either doesn't call PR_Cleanup or
has some thread that is still alive at process termination.
The former is more likely because I recommend against
calling PR_Cleanup in general.  The reason is that many
applications still use NSPR inadvertently after they call
PR_Cleanup.

I need more information from BoundsChecker on the thread
in question before I can resolve this bug.  In particular
I need to know whether the thread whose semaphore handle
is leaked is the primordial thread (the thread that executes
the main function) or some other thread.

Comment 2

[Itay Perl]

How can I tell you that?

Comment 3

[Wan-Teh Chang]

A complete stack trace of that thread would be sufficient.

Comment 4

[Itay Perl]

I'm not sure I get you right, cuz I'm new to debugging and stuff..Will the list
in BoundsChecker's Allocation Call Stack be sufficient (list of functions)? It
reaches _PR_MD_INIT_THREAD through PR_NewLogModule.
(mozilla\nsprpub\pr\src\io\prlog.c). If more information is needed, tell me.

Comment 5

[Wan-Teh Chang]

Yes, that is sufficient.  Just make sure the call stack
is complete and not truncated.

Comment 6

[Itay Perl]

This is the list from BoundsChecker:
                 	C:\WINNT\system32\ntdll.dll
_DllMainCRTStartup	crtdll.c
_CRT_INIT	        crtdll.c
_initterm	        crt0dat.c
$E56	                mozilla\objs\dist\bin\xpcom_core.dll
$E55	                mozilla/xpcom/build/xpcom/threads\nsTimerImpl.h Line 57
PR_NewLogModule         mozilla/nsprpub/pr/src/io/prlog.c           	Line 359
PR_ImplicitInitialization  mozilla/nsprpub/pr/src/misc/prinit.c	        Line 258
PR_InitStuff	        mozilla/nsprpub/pr/src/misc/prinit.c	        Line 216
PR_InitThreads	      mozilla/nsprpub/pr/src/threads/combined/pruthr.c  Line 162
PR_MD_INIT_THREAD	mozilla/nsprpub/pr/src/md/windows/w95thred.c	Line 105









 

Comment 7

[Wan-Teh Chang]

Thanks for the stack trace.  This thread is indeed
the primordial thread.  (At the time the semaphore
was created, the thread had not got to the main()
function yet.)  The only way to free the semaphore
and other NSPR resources owned by the primordial
thread is to call PR_Cleanup.  But it is not easy
to call PR_Cleanup safely in a complex application
like Mozilla and Firefox because NSPR is used everywhere
and it's not easy to ensure that nobody will be using
NSPR after PR_Cleanup is called.  So I recommend
against using PR_Cleanup in general.

This means when running a program like Purify or
BoundsChecker, you should ignore all resources
allocated in PR_ImplicitInitialization.