I have a multithreaded win32 application that does both C++ style memory allocation
using the “new” operator and C style “malloc”. You can guess that I inherited
(ended up owning) this app that was written by 2 different people in 2 different time
zones in a hurry. I did some work to integrate the different pieces and wrote the kernel
component for it.
The problem I am facing is that memory returned from malloc overlaps the memory
returned from new in the application. You can guess the havoc this will cause.
This happens very rarely (or is a problem for our application rarely). In 2 years of
use on several thousand different win2k, winxp and win2003 systems, we have been
able to see this problem consistently only on 2 systems.
I tried compiling the source modules in the following 2 ways and both resulting versions
of app binaries have the same symptom on the problematic system.
compile all source modules in Microsoft Platform SDK command line using (Makefile):
cl -Zi -Od -DDEBUG -c -DCRTAPI=_cdecl -DCRTAPI2=cdecl -nologo -GS -D_X86=1 -D_WIN32 -DWIN32 -W3 -D_WIN32_WINNT=0X0500 -EHsc -Zi /MT source.cpp
Same compile flags as above for source.c
I tried linking the above resulting .objs by following 2 different commands:
link /DEBUG /NODEFAULTLIB:libc.lib source1.obj source2.obj … sourcen.obj Mpr.lib advapi32.lib
and
link /DEBUG /NODEFAULTLIB:libc.lib source1.obj source2.obj … sourcen.obj Mpr.lib advapi32.lib libcmt.lib
Note that the application is multi threaded.
Is there a simple explanation to this problem? This problem could be trivial for
the exprienced readers on this list.
I wonder, are you sure this is a kernel mode question?
wrote in message news:xxxxx@ntdev…
>I have a multithreaded win32 application that does both C++ style memory
>allocation
> using the “new” operator and C style “malloc”. You can guess that I
> inherited
> (ended up owning) this app that was written by 2 different people in 2
> different time
> zones in a hurry. I did some work to integrate the different pieces and
> wrote the kernel
> component for it.
>
> The problem I am facing is that memory returned from malloc overlaps the
> memory
> returned from new in the application. You can guess the havoc this will
> cause.
> This happens very rarely (or is a problem for our application rarely). In
> 2 years of
> use on several thousand different win2k, winxp and win2003 systems, we
> have been
> able to see this problem consistently only on 2 systems.
>
> I tried compiling the source modules in the following 2 ways and both
> resulting versions
> of app binaries have the same symptom on the problematic system.
>
> compile all source modules in Microsoft Platform SDK command line using
> (Makefile):
> cl -Zi -Od -DDEBUG -c -DCRTAPI=_cdecl -DCRTAPI2=cdecl -nologo -GS -D_X86=1
> -D_WIN32 -DWIN32 -W3 -D_WIN32_WINNT=0X0500 -EHsc -Zi /MT source.cpp
>
> Same compile flags as above for source.c
>
> I tried linking the above resulting .objs by following 2 different
> commands:
>
> link /DEBUG /NODEFAULTLIB:libc.lib source1.obj source2.obj … sourcen.obj
> Mpr.lib advapi32.lib
>
> and
>
> link /DEBUG /NODEFAULTLIB:libc.lib source1.obj source2.obj … sourcen.obj
> Mpr.lib advapi32.lib libcmt.lib
>
> Note that the application is multi threaded.
>
> Is there a simple explanation to this problem? This problem could be
> trivial for
> the exprienced readers on this list.
>
Even if it’s not possibly a kernel dev question…
New and malloc are compatible, in the sense that you can use both of them in
the same application. And actually, if you think this done in all the
applications, even if you use only new/delete in your app, the DLLs that you
are using (and you are always using some DLLs!) will have their own memory
allocation strategy, being it new/delete, malloc/free, LocalAlloc/LocalFree
or any other.
Having said that, you need to be *very* careful on this, when you use
new/delete and malloc/free:
- always use corresponding allocators/deallocators. You cannot delete some
memory allocated by new with free. Ok, this is obvious…
- be very careful to use the same *exact* CRT (C-Runtime) for the new and
delete operation (or malloc/free). This means that if you allocate some
memory in a DLL with malloc, you should free that memory within the same DLL
(i.e. don’t allow you DLL caller to free that memory). Different versions of
the CRT (debug/release, single or multithreaded, static lib or DLL,
different builds of the CRT) have different memory allocation strategies.
The same applies to FILE descriptors returned by fopen() and similar.
There’s a specific MS KB for this, but I cannot easily find it now…
- you said that you app is multithreaded. Another obvious thing: be sure
that all the modules are compiled with the “multithreading” enabled. This
means using /MT (or /MTd or /MD or MDd) in the compilation options (like you
seem to be doing in the command line below).
Hope it helps
GV
“Lyndon J. Clarke” wrote in message
news:xxxxx@ntdev…
>I wonder, are you sure this is a kernel mode question?
>
> wrote in message news:xxxxx@ntdev…
>>I have a multithreaded win32 application that does both C++ style memory
>>allocation
>> using the “new” operator and C style “malloc”. You can guess that I
>> inherited
>> (ended up owning) this app that was written by 2 different people in 2
>> different time
>> zones in a hurry. I did some work to integrate the different pieces and
>> wrote the kernel
>> component for it.
>>
>> The problem I am facing is that memory returned from malloc overlaps the
>> memory
>> returned from new in the application. You can guess the havoc this will
>> cause.
>> This happens very rarely (or is a problem for our application rarely).
>> In 2 years of
>> use on several thousand different win2k, winxp and win2003 systems, we
>> have been
>> able to see this problem consistently only on 2 systems.
>>
>> I tried compiling the source modules in the following 2 ways and both
>> resulting versions
>> of app binaries have the same symptom on the problematic system.
>>
>> compile all source modules in Microsoft Platform SDK command line using
>> (Makefile):
>> cl -Zi -Od -DDEBUG -c -DCRTAPI=_cdecl -DCRTAPI2=cdecl -nologo -GS -D_X86=1
>> -D_WIN32 -DWIN32 -W3 -D_WIN32_WINNT=0X0500 -EHsc -Zi /MT source.cpp
>>
>> Same compile flags as above for source.c
>>
>> I tried linking the above resulting .objs by following 2 different
>> commands:
>>
>> link /DEBUG /NODEFAULTLIB:libc.lib source1.obj source2.obj …
>> sourcen.obj Mpr.lib advapi32.lib
>>
>> and
>>
>> link /DEBUG /NODEFAULTLIB:libc.lib source1.obj source2.obj …
>> sourcen.obj Mpr.lib advapi32.lib libcmt.lib
>>
>> Note that the application is multi threaded.
>>
>> Is there a simple explanation to this problem? This problem could be
>> trivial for
>> the exprienced readers on this list.
>>
>
>
>
I think you should also try using app verifier or the CRT heap allocation debugging functions- your issue could well be a buffer overrun in the app clobbering a free list or other management structure in the heap manager, rather than having anything to do with mixing allocators.
Should have also added PreFast and / or some form of lint to that suggestion…
-----Original Message-----
From: Bob Kjelgaard
Sent: Thursday, November 16, 2006 8:50 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] new and malloc allocators incompatible?
I think you should also try using app verifier or the CRT heap allocation debugging functions- your issue could well be a buffer overrun in the app clobbering a free list or other management structure in the heap manager, rather than having anything to do with mixing allocators.
Thanks for the many suggestions. No this is not a kernel dev question. There are 2 parts to the
product, the application (user mode) component and a kernel mode component. The user mode
component is the one having trouble with memory allocations.