Operator new in different DLL'S?
Matthias Bohlen -- MATTES@logotec.com
Monday, April 01, 1996
Hello,
I have an MFC program with several MFC extension DLL's. Does anyone
know if it is safe to call operator new in one DLL and operator
delete in another on the same object?
Does this depend on using DEBUG_NEW or not?
Any help would be appreciated.
Matthias Bohlen
-------------------------------------------------------
Matthias Bohlen Logotec Software GmbH
Phone: +49 228 64 80 520 Chateauneufstr. 10
FAX: +49 228 64 80 525 D-53347 Alfter, Germany
E-mail: mattes@logotec.com
-------------------------------------------------------
Elliott Kleinrock -- ELLIOTT@flexi.com
Tuesday, April 02, 1996
[Mini-digest: 8 responses]
[Moderator's note: I screwed up on this one. Mattes forgot to
specify the environment and I didn't send it back for more info.
Like it says in the info message: I reserve the right to screw up.]
I have found that if the object you are creating also creates other
objects, then it is best to override the new and delete operators for
the first object. This will cause both news and both deletes to take
place in the same address space.
In any case supplying your own new and delete makes sure that
all memory is allocated from the same space.
I am using SmartHeap by MicroQuill, so my mileage may vary.
- Elliott (elliott@flexi.com)
----------
-----From: "David W. Gillett"
I don't see how this could be a problem.
You don't specify the platform, but I'll assume Win32. In Win16,
objects new'ed or malloc'ed from a DLL should be in a shared segment
belonging to the DLL, but in Win32 they should just be somewhere in
the task's address space. As long as the code that manipulates the
heap is thread-safe (not an issue in 16-bit code), it should be fine.
Dave
-----From: grossman@teleport.com (Jeff Grossman)
It is entirely safe to do this provided you use the DLL version of the
C run-time library. If you statically link the C run-time library, the
delete will cause R6018 error ("invalid pointer passed to RTLFreeHeap")
because each copy of the RTL will create its own heap.
I generally use the Multi-Threaded DLL version.
To my knowledge, debug does not change this. Of course, your RTL will
be the "Debug ... DLL".
This option (in VC4) is set in the build settings dialog, C++ page,
"Code Generation" option.
Jeff
-----From: Gonzalo Isaza
You should be sharing the CRT functions which take care of heap
handling, so the operation should be safe. If one of the DLL's has
statically linked the CRT library in it, then you would end up having 2
heaps and the operation you describe would fail. Even in the case of
failure the CRT has a way to check this situation and an ASSERT should
go off (in the debug version of course) if you end up with 2 heaps.
Gonzalo Isaza [I speak for myself. I don't speak for Microsoft]
-----From: SANDEEP@novell.com (Sandeep Khamesra)
I think it is very Safe to Call a new in one
DLL and Delete in other as long as u r
working in Windows 95.
Actually In Windows 95 DLL make use of
Process's Data Segement. So any allocation
will be done in Process's data segement.
Now the other DLL will also share the same
Data Segemnt. So if u have that pointer in
that DLL it can delete with no problem
Hope this helps.
Reply if u differ in the opinion..
Sandy
-----From: Chong Zhang
As long as these MFC extension DLLs are sharing MFC DLLs, you will not
have any problem. Because all the memory management routines are handled
in the MFC application not in the DLL.
If one of those DLLs uses a static copy of MFC, you are basicly out of
luck. Even though it is not impossible to do, the matter of fact I did
just like that in one of my project, but I don't think you
will like to handle routing all these memory allocation/deallocation to
the proper place and to overcome some of MFC design flaw.
-----From: CraigTT_at_USNELMIS@ccmail01.PE-Nelson.COM
Matthias,
If your app and the DLLs are linked to the DLL version of the C++
runtime library AND you're using the default new (i.e. operator new
hasn't been overloaded in some strange and wonderful way), you should
be able to do what you want allocating one place and freeing another.
If you're linked to the static library version of the runtime lib,
you'll most likely have problems.
Tim Craig
PE-Nelson
-----From: mikeblas@interserv.com
In MFC 4.x, all of the memory management is done by the C Runtime library. If
all the DLLs that are sharing memory (and all the applications, if any) are
using the same type of CRuntime library, you're fine. This means that if one
DLL is using a "Debug Multithreadded DLL" runtime library, _everyone_ must be
using a "Debug Multithreadded DLL" runtime library build. Period. You must
make an exact match.
In MFC 2.x, the same rules apply, but they apply to MFC instead. Back in MFC
2.x, MFC was the one taking care of memory management for debug builds. If
any MFC module in question is built for debugging, the all must be built for
debugging.
.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for Microsoft.");
Michael Foster -- mfoster@ontime.com
Thursday, April 04, 1996
Refer to the Microsoft knowledge base article Q122675 - "BUG: Wrong Operator
Delete Called for Exported Class". It describes problems with cross DLL
memory management and offers some solutions. The specific bug they are
talking about is as follows:
"When allocating and deleting an object of a class that is exported from a
DLL, you may find that the new operator in the EXE is called to allocate the
memory but the delete operator in the DLL is called to delete the memory.
Therefore, there is a new/delete mismatching problem, which may cause
run-time errors."
-------------
Original Text
>From ELLIOTT@SMTP (Elliott Kleinrock) {ELLIOTT@flexi.com}, on 4/2/96 9:55
am:
[Mini-digest: 8 responses]
[Moderator's note: I screwed up on this one. Mattes forgot to
specify the environment and I didn't send it back for more info.
Like it says in the info message: I reserve the right to screw up.]
I have found that if the object you are creating also creates other
objects, then it is best to override the new and delete operators for
the first object. This will cause both news and both deletes to take
place in the same address space.
In any case supplying your own new and delete makes sure that
all memory is allocated from the same space.
I am using SmartHeap by MicroQuill, so my mileage may vary.
- Elliott (elliott@flexi.com)
----------
-----From: "David W. Gillett"
I don't see how this could be a problem.
You don't specify the platform, but I'll assume Win32. In Win16,
objects new'ed or malloc'ed from a DLL should be in a shared segment
belonging to the DLL, but in Win32 they should just be somewhere in
the task's address space. As long as the code that manipulates the
heap is thread-safe (not an issue in 16-bit code), it should be fine.
Dave
-----From: grossman@teleport.com (Jeff Grossman)
It is entirely safe to do this provided you use the DLL version of the
C run-time library. If you statically link the C run-time library, the
delete will cause R6018 error ("invalid pointer passed to RTLFreeHeap")
because each copy of the RTL will create its own heap.
I generally use the Multi-Threaded DLL version.
To my knowledge, debug does not change this. Of course, your RTL will
be the "Debug ... DLL".
This option (in VC4) is set in the build settings dialog, C++ page,
"Code Generation" option.
Jeff
-----From: Gonzalo Isaza
You should be sharing the CRT functions which take care of heap
handling, so the operation should be safe. If one of the DLL's has
statically linked the CRT library in it, then you would end up having 2
heaps and the operation you describe would fail. Even in the case of
failure the CRT has a way to check this situation and an ASSERT should
go off (in the debug version of course) if you end up with 2 heaps.
Gonzalo Isaza [I speak for myself. I don't speak for Microsoft]
-----From: SANDEEP@novell.com (Sandeep Khamesra)
I think it is very Safe to Call a new in one
DLL and Delete in other as long as u r
working in Windows 95.
Actually In Windows 95 DLL make use of
Process's Data Segement. So any allocation
will be done in Process's data segement.
Now the other DLL will also share the same
Data Segemnt. So if u have that pointer in
that DLL it can delete with no problem
Hope this helps.
Reply if u differ in the opinion..
Sandy
-----From: Chong Zhang
As long as these MFC extension DLLs are sharing MFC DLLs, you will not
have any problem. Because all the memory management routines are handled
in the MFC application not in the DLL.
If one of those DLLs uses a static copy of MFC, you are basicly out of
luck. Even though it is not impossible to do, the matter of fact I did
just like that in one of my project, but I don't think you
will like to handle routing all these memory allocation/deallocation to
the proper place and to overcome some of MFC design flaw.
-----From: CraigTT_at_USNELMIS@ccmail01.PE-Nelson.COM
Matthias,
If your app and the DLLs are linked to the DLL version of the C++
runtime library AND you're using the default new (i.e. operator new
hasn't been overloaded in some strange and wonderful way), you should
be able to do what you want allocating one place and freeing another.
If you're linked to the static library version of the runtime lib,
you'll most likely have problems.
Tim Craig
PE-Nelson
-----From: mikeblas@interserv.com
In MFC 4.x, all of the memory management is done by the C Runtime library.
If
all the DLLs that are sharing memory (and all the applications, if any) are
using the same type of CRuntime library, you're fine. This means that if
one
DLL is using a "Debug Multithreadded DLL" runtime library, _everyone_ must
be
using a "Debug Multithreadded DLL" runtime library build. Period. You must
make an exact match.
In MFC 2.x, the same rules apply, but they apply to MFC instead. Back in
MFC
2.x, MFC was the one taking care of memory management for debug builds. If
any MFC module in question is built for debugging, the all must be built for
debugging.
.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for
Microsoft.");
| Вернуться в корень Архива
|