Re: EncryptMessage Memory leak

John,

You are correct about the dlls, thanks for pointing that out.

I should say in any case that these two libraries are the main difference
between the dlls loaded by the VC2005 and the VC6 apps. All else appears to
be the same.

Certainly ntdll.dll is identical.

Yet memory continues to be leaked in the EncryptMessage call (I've proved
this by single stepping the code). However I may try using boundschecker or
the tool you suggested to zero in on exactly which module this leak is
happening in.

If msvcr80.dll is the c run-time dll for VC2005, what is msvcrt.dll?

Anyway msvcr80.dll has no clear equivalent in the VC6 build.



"John Banes" wrote:

The MSVCR80.dll and MSVCP80.dll binaries have similar names, but they're not
the same. Did you overlook this?

As I recall, neither the EncryptMessage function itself nor any of the
binaries it depends on make use of the MSVC CRT. Instead, they use the
functions in NTDLL.DLL. At least, that was the goal. :-)

You might try reconfiguring your VC2005 project so that it uses the
statically-linked version of the MSVC CRT rather than the DLLs and see if
that makes a difference. It should take the DLLs out of the process memory
image, anyway, and that would simplify the problem. I often build VC2005
projects this way, so that I can use the debug CRT without having to bother
with installing the debug DLLs and associated manifest. The "Runtime
Library" option is located in the "Code Generation" pane, under "C/C++".

Regards,
John



"codemutt" <codemutt@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:413237CD-4A2C-40E1-BE26-81927A84FC20@xxxxxxxxxxxxxxxx
When I say it's a problem with the function, I should be clearer: one of
the
runtime libraries EncryptMessage uses with VC2005 must be leaking.

My last post implied secur32.dll was different -- that's wrong and not
what
I meant to say. In fact both the VC6 and VC8 exe load the same
secur32.dll.

HOWEVER (writ big), when I look at what each process loads in terms of
dlls,
there is an interesting difference: The VC6 naturally loads MSVCP60.dll
and
the VC2005 loads (and this I don't understand at all) TWO instances of the
same file: MSVCR80.dll. They are loaded at different base addresses and
have
different sizes. All in one .exe file mapping.

Maybe I have screwed up a compiler setting somehow in VC8 to get it to
load
the VC8 runtime twice ... but ... uh. Hmm. If calls are somehow split
between
these two dlls then I could see how you'd leak memory.

Anyway all the other files loaded by the VC6 and VC8 process are
identical.

Here's some details. First number is base address, next number is size,
then
comes version info, then location ...

VC8:
0x78130000 0x9b000 8.00.50727.0042
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd\MSVCR80.dll
0x7c420000 0x87000 8.00.50727.0042
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd\MSVCP80.dll




"codemutt" wrote:

It is a problem with the function.

Code changes occur all the time between releases. It's very easy to
introduce a memory leak (that's why Microsoft is providing a managed
environment for us poor "regular" developers with .NET's CLR). The
library
that ships with VC2005 is not identical with the SP1 SDK.

I have used sophisticated memory tracking tools -- but they aren't
necessary
to uncover this goof.

The library function EncryptMessage shipped with VC2005 leaks memory
after
it is called with sufficient data, whereas the library function shipped
with
Windows 2003 SP1 SDK does not leak memory.

It is very simple for others to verify this. I'm hoping someone from
Microsoft will take this up and either vigorously deny it or affirm it as
a
problem.

"John Banes" wrote:

Well, the secure32!EncryptMessage function doesn't change just because
you're using VC2005, and so I wouldn't think that it's a problem with
the
function itself. :-)

I'm not sure what the problem is, but I would suggest using a proper
leak
detection tool rather than the task manager, and see if that's able to
point
you in the right direction. My favorite is umdh.exe, which ships free
with
the Microsoft debugger package.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx

In general, I prefer using the header files and libraries from the
Windows
SDK rather than the ones shipped with the compiler. They tend to line
up
better with the target operating system.

Best of luck,
John

"codemutt" <codemutt@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:060C4FB6-AAFE-45BA-811C-14523C0D260E@xxxxxxxxxxxxxxxx
I am seeing what appears to be a memory leak in EncryptMessage.

I have a project that I can compile in VC6 using the Windows Server
2003
SPI
platform SDK. All the program does is use the SSPI interface as
illustrated
in webclient.c to send the contents of a statically declared string
object
to
a server over an SSL channel. Note that it is not webclient.c but
does
things
the same way.

The app runs fine when I use the security libraries from the SP1 SDK.

The same exact code when compiled with Visual Studio 2005 (no SDK,
just
utilizing the headers and libraries that come with 2005) shows a
rather
bad
memory leak apparently INSIDE EncryptMessage.

VC6 + SDK (Win2003 SP1): no leak in EncryptMessage.
VC2005: leak in EncryptMessage.

Running identical code built with these two different libraries
results in
a
binary I can see via Task Manager after a few hours amazing
differences:

VC6 + SDK: ~9824K (steady from start throughout test)
VC2005: 30000K and rising ... (climbing rapidly throughout test)

The code path is identical and no application memory is being
allocated.

Task Manager shows the leak increment heap usage immediately after
the
call
to EncryptMessage (but never before).

Anyone else notice this? Has it been addressed in a subsequent
Service
Pack
for 2005 or an SDK release?



.

Relevant Pages

  • Re: MDAC memory leak
    ... Most libraries place the decision of when to free ... There's a capability of breaking on a particular memory allocation, ... leak 500 objects, on the second test I leak 3, because I fixed the bug). ... "App shows memory leak on some machines." ...
    (microsoft.public.vc.mfc)
  • Re: EncryptMessage Memory leak
    ... I have used sophisticated memory tracking tools -- but they aren't necessary ... Windows 2003 SP1 SDK does not leak memory. ... I prefer using the header files and libraries from the Windows ...
    (microsoft.public.platformsdk.security)
  • Re: EncryptMessage Memory leak
    ... neither the EncryptMessage function itself nor any of the binaries it depends on make use of the MSVC CRT. ... It should take the DLLs out of the process memory image, anyway, and that would simplify the problem. ... these two dlls then I could see how you'd leak memory. ... I prefer using the header files and libraries from the> Windows ...
    (microsoft.public.platformsdk.security)
  • Re: Dlls,memory allocation
    ... quite a few dlls and execute. ... be no dynamic memory in the libraries.. ... In that case, the allocation /freeing will ...
    (comp.lang.c)
  • Re: Dlls,memory allocation
    ... quite a few dlls and execute. ... be no dynamic memory in the libraries.. ... In that case, the allocation /freeing will ...
    (comp.lang.c)