Memory leak when creating & destroying thread

We have large CE 5.0 app that runs on proprietary X86 hardware that leaks
memory when threads are created and destroyed. We have made sure that the
thread handles are being closed, etc. but continues to occur. Has anyone
run into this? Are there any QFE's related to this (we have not applied
QFE's since Q1 of 05 becuase of other bad side effects)?

Valter
Mon Jun 19 12:26:40 CDT 2006

"Bill T" <billthe@charter.net> wrote in
news:#uvniR8kGHA.4888@TK2MSFTNGP02.phx.gbl:

[...]

I forgot to add that you may use appverifier tool to check your
application leaks.



--
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

Valter
Mon Jun 19 12:25:49 CDT 2006

"Bill T" <billthe@charter.net> wrote in
news:#uvniR8kGHA.4888@TK2MSFTNGP02.phx.gbl:

> We have large CE 5.0 app that runs on proprietary X86 hardware
> that leaks memory when threads are created and destroyed. We have
> made sure that the thread handles are being closed, etc. but
> continues to occur. Has anyone run into this? Are there any
> QFE's related to this (we have not applied QFE's since Q1 of 05
> becuase of other bad side effects)?
>

Just some questions to understand your configuration:

- How do you create the thread? A call to CreateThread or some wrapper
provided by MFC or other libraries?
- How do you destroy the thread? It terminates the execution of its
thread function or you kill it using terminatethread, exit or other
ways?
- A simple application that spawns threads and let them terminate or
kills them shows the same leakage?


--
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

BillT
Tue Jun 20 13:43:01 CDT 2006

Valter

We are using standard Win32 api's, do not call TerminatThread() but depend
upon ExitThread() being call automatically (there is extensive discussion in
old postings stating that this is the preferred approach - also in Petzold's
WIN32 bible).

I hope to try AppVerifier - what does it report that would point to the
source of this problem?

Thanks
"Valter Minute" wrote:

> "Bill T" <billthe@charter.net> wrote in
> news:#uvniR8kGHA.4888@TK2MSFTNGP02.phx.gbl:
>
> [...]
>
> I forgot to add that you may use appverifier tool to check your
> application leaks.
>
>
>
> --
> Valter Minute
> (the reply address of this message is invalid)
> (l'indirizzo di reply di questo messaggio non è valido)
>

Valter
Wed Jun 21 02:24:21 CDT 2006

=?Utf-8?B?QmlsbCBU?= <BillT@discussions.microsoft.com> wrote in
news:FC3D13C5-4CF7-4E77-8D2F-8205A41849BD@microsoft.com:

[...]
> I hope to try AppVerifier - what does it report that would point
> to the source of this problem?

You may read something more about AppVerifier on this (long) link:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnce50/html/appverifier_wince.asp

--
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

BillT
Wed Jun 21 11:55:02 CDT 2006

Valter

Thanks for this link, it is extremely useful!!!

But, the output from AppVerifier also raises a few questions. The output
below seems to indicate that COleStaticMutexSem in ole32.dll is leaking a
critical section handle. Is this correct?

If so, does anyone have any idea what I can do about this since it is in
code that MS does not deliver as source?

# DESCRIPTION BEGIN
Gives the callstack for a handle that leaked
# DESCRIPTION END
| shim_hleak.dll 28 | 2 shim_hleak.dll 0'Leaked handle values:
| shim_hleak.dll 28 | 2 shim_hleak.dll 0'CRITSEC Handle = 0x01f7fc28 ''
| shim_hleak.dll 28 | 2 shim_hleak.dll 0'CALL STACK
| shim_hleak.dll 28 | 2 shim_hleak.dll 0'PC=0x17234546 shim_hleak.dll! + 4546h
| shim_hleak.dll 28 | 2 shim_hleak.dll 0'PC=0x172344ba shim_hleak.dll! + 44bah
| shim_hleak.dll 28 | 2 shim_hleak.dll 0'PC=0x17234853 shim_hleak.dll! + 4853h
| shim_hleak.dll 28 | 2 shim_hleak.dll 0'PC=0x03b3c69f
ole32.dll!?Init@COleStaticMutexSem@@QAEXXZ + ch
| shim_hleak.dll 28 | 2 shim_hleak.dll 0'PC=0x03b2b8da
ole32.dll!?wCoCreateInstance@@YAJABU_GUID@@PAUIUnknown@@K0PAPAX@Z + 26h
| shim_hleak.dll 28 | 2 shim_hleak.dll 0'PC=0x160112ad consumerut.exe! +
112adh
# LOGENTRY shim_hleak.dll 29 'Leaked 1 handles that were allocated at this
stack


"Valter Minute" wrote:

> =?Utf-8?B?QmlsbCBU?= <BillT@discussions.microsoft.com> wrote in
> news:FC3D13C5-4CF7-4E77-8D2F-8205A41849BD@microsoft.com:
>
> [...]
> > I hope to try AppVerifier - what does it report that would point
> > to the source of this problem?
>
> You may read something more about AppVerifier on this (long) link:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/dnce50/html/appverifier_wince.asp
>
> --
> Valter Minute
> (the reply address of this message is invalid)
> (l'indirizzo di reply di questo messaggio non è valido)
>

Valter
Thu Jun 22 02:44:50 CDT 2006

=?Utf-8?B?QmlsbCBU?= <BillT@discussions.microsoft.com> wrote in
news:972ACCBF-06FD-4102-BD79-5688EDB79191@microsoft.com:

> Valter
>
> Thanks for this link, it is extremely useful!!!
>
> But, the output from AppVerifier also raises a few questions. The
> output below seems to indicate that COleStaticMutexSem in
> ole32.dll is leaking a critical section handle. Is this correct?
[...]

In some cases AppVerifier reports some leaks because a program or a
DLL doesn't destroy a global object on application exit. Since the
object is destroyed by the OS when the application terminates this is
not a big issue (it could became an issue on a DLL that is
loaded/unloaded many times).
Usually the "dangerous" leaks are those that happen many times during
the execution of an application (like the one your reported about
threads).

> If so, does anyone have any idea what I can do about this since it
> is in code that MS does not deliver as source?
[...]

You could try to report this to MS as a bug or as a suspected bug.

--
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

Valter
Thu Jun 22 02:46:47 CDT 2006

=?Utf-8?B?QmlsbCBU?= <BillT@discussions.microsoft.com> wrote in
news:972ACCBF-06FD-4102-BD79-5688EDB79191@microsoft.com:

[...]

I fogot to say that a leak in a DLL could be due to a leak inside an
application, that doesn't call a "release" method for something that
has been allocated inside the DLL.
For example, if you create a COM object and never release it, the leak
is reported on the DLL that allocated the object but you'll have to fix
the application and not the DLL.

--
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

BillT
Thu Jun 22 11:10:02 CDT 2006

Valter
Thanks for the info.

Off hand, do you know the evc++ project settings that producing listing
files with offsets coorresponding to those in the log files?

For Example: In the webarticle Leaker3 example AppVerifier reports a thread
handle leak at Leaker3.exe + 30h and the listing file for Leaker3.cpp shows
"00030 eb000000 b1 CreateThread" where 00030 is the offset. I need to
create a listing file with offsets for my apps in order to determine where
the leaks are occurring.

Thanks

"Valter Minute" wrote:

> =?Utf-8?B?QmlsbCBU?= <BillT@discussions.microsoft.com> wrote in
> news:972ACCBF-06FD-4102-BD79-5688EDB79191@microsoft.com:
>
> [...]
>
> I fogot to say that a leak in a DLL could be due to a leak inside an
> application, that doesn't call a "release" method for something that
> has been allocated inside the DLL.
> For example, if you create a COM object and never release it, the leak
> is reported on the DLL that allocated the object but you'll have to fix
> the application and not the DLL.
>
> --
> Valter Minute
> (the reply address of this message is invalid)
> (l'indirizzo di reply di questo messaggio non è valido)
>

Valter
Thu Jun 22 11:21:43 CDT 2006

=?Utf-8?B?QmlsbCBU?= <BillT@discussions.microsoft.com> wrote in
news:BC8981A7-3EE2-4B17-B6CC-AFEB0F1D6E6A@microsoft.com:

> Valter
> Thanks for the info.
>
> Off hand, do you know the evc++ project settings that producing
> listing files with offsets coorresponding to those in the log
> files?

I don't understand your question.
To generate listing files you've to enable the corresponding option in
the compiler's configuration tab of your project settings.
The offsets are always calculated from the beginning of the function,
since the linker could re-arrange them or remove some functions that
are never called.
You need to use the map file to calculate the entry point of the
function and then calculate the offset from its beginning. I don't know
any tool that does that, but it could be a useful thing...

--
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

Bill
Thu Jun 22 20:13:26 CDT 2006

Your description is what I was looking for and found in some our past work.

Thanks

BTW - If I create a default COM project using the evc++ wizard (nothing
added by user), build it in evc++ and then run it in App Verifier, there are
9 reported leaks. That seems quite bad to me!

"Valter Minute" <vminute@GoogleMAILservice.com> wrote in message
news:Xns97EABACE3C419VALTERMINUTE@207.46.248.16...
> =?Utf-8?B?QmlsbCBU?= <BillT@discussions.microsoft.com> wrote in
> news:BC8981A7-3EE2-4B17-B6CC-AFEB0F1D6E6A@microsoft.com:
>
>> Valter
>> Thanks for the info.
>>
>> Off hand, do you know the evc++ project settings that producing
>> listing files with offsets coorresponding to those in the log
>> files?
>
> I don't understand your question.
> To generate listing files you've to enable the corresponding option in
> the compiler's configuration tab of your project settings.
> The offsets are always calculated from the beginning of the function,
> since the linker could re-arrange them or remove some functions that
> are never called.
> You need to use the map file to calculate the entry point of the
> function and then calculate the offset from its beginning. I don't know
> any tool that does that, but it could be a useful thing...
>
> --
> Valter Minute
> (the reply address of this message is invalid)
> (l'indirizzo di reply di questo messaggio non è valido)