I have a problem according to client & dll memory handling
The dll is a regular dll. I can link it dynamically or statically.
Both, client & dll are using mfc.

I have a client which "news" a variable

lets say

    int *a = new a;

now I call a dll function with passing the pointer it.

within the dll function I say

    delete a;

now the crt throws an exeption.
the reason is, that the client and the dll have their own separate heaps
which is created by the C Runtime Library. The dll function tries to free
the memory allocated for "a" in context of its own heap. Its  plausible
that this nice try crashes, because that memory was never allocated on the
heap of the dll, but on that of the Client.

Is there something important to do, so that client & dll use the same heap
(i.e. global process heap) or do I have to forget about using "new" and
"delete".

I think this is very strange, I had expected that client & dll use the same
heap, so I would can use new & delete over client/dll boundaries.

In advance, thanks for any answer.
Jakob Ott

Hi,

Change in project settings, C/C++ tab under code generation category value of
use runtime library to "Multithreaded DLL" or "Multithreaded debug DLL". This
should do the trick.

-------------------------------------------------------------
Mika Kurki - System Analyst, ICL Financial Services

to respond remove zzz from start of the address

Another person pointed out switching to the DLL version of the Runtime
library, however, there are several considerations here.  Note that if
you're using a debug exe and a release DLL (or vice versa) you're still
going to have problems because they still won't match.

In general the "standard" way to do this is to define a common point of
memory creation and deletion.

FWIW, in my projects what I've done is to create a new function (method,
whatever) that is exported by the DLL that does the memory allocation
(usually it does it in terms of "tell me what you want in this new thing,
I'll allocate the memory and do the assignments for you"), and another new
function exported by the DLL that does the memory deallocation.

Therefore, a simple view would be:

NewFoo = CreateFoo(FooParameters);
OperateOnFoo(NewFoo);
DestroyFoo(NewFoo);

This will eliminate your problems entirely.

Also note that in COM where this issue pops up constantly, there are global
functions (Called "CoTaskMemAlloc" and "CoTaskMemFree") which resolve this
issue of crossing DLL/Process/Machine boundaries.

HTH

--
Reginald Blue                   | Opinions expressed here do not
Natural Language Understanding  | necessarily represent those of
Unisys Corporation              | my employer.
                                |-------------------------------
                                | My email address is wrong, you

    Hi Is this documented somewhere? I'm hunting down an problem where
memory which is allocated in the main execuatble is deleted in the va of the
dll.
This is confirmed as a compiler bug in the Microsoft Visual C== 1.0 untill
5.0. The article is Q122675, last reviewed July 29 1998.

This stops us from splitting up mjor parts of our code into dll's

    thanks in advandge,
    Rob

Rob,

 > This is confirmed as a compiler bug in the Microsoft Visual C

Despite what the KB article says (does it call it a bug?), it is _not_ a
bug. If anything it is a wart, as it was designed that way.

Furthermore, I don't see a way around the issue, so you have only two
choices:

        - live with it
        - or use the DLL runtime, and make damn sure that every
          module uses the _same_ runtime DLL.

--

Cheers,

Felix.

If you post a reply, kindly refrain from emailing it, too.

No anti-spam address here. Just one comment: IN YOUR FACE!

Reginald,

 > Note that if you're using a debug exe and
 > a release DLL (or vice versa) you're still
 > going to have problems because they still
 > won't match.

Actually, you still can pick whatever DLL you wish. I regularly link my
debug build with release run-times.

--

Cheers,

Felix.

If you post a reply, kindly refrain from emailing it, too.

No anti-spam address here. Just one comment: IN YOUR FACE!

Hi,

The point to get memory allocation to work is to use memory allocation and
deallocation routines as pairs. Lik:
GlobalAlloc - GlobalFree
new - delete
malloc - free
CoTaskMemAlloc - CoTaskMemFree

with new and malloc which are C runtime library routines there are additional
restriction that they must come from same C runtime library. So for example
new from Release MSVCRT40.dll and delete from Debug MSVCRT20.DLL don't work
together.

If you are statically linking C-runtime (non -dll version in use runtime
library setting in Visual Studio) in your own DLL then this DLL has its own
copy of C runtime library and memory allocated in this DLL cannot be safely
destroyed in another DLL or EXE. If you dynamically link C runtime library to
your dll then you share C runtime with other DLLs and EXE which has also
dynamically linked C runtime and then memory allocated in one module can be
freed in another module. Supposing both modules are using same version
(Release/Debug  and version number) of C runtime.

I didn't fully understand if the problem in article Q12267 appears only when
there are globally overridden version of new and delete or always. Anyway if
you use correct setting to ensure that new and delete both in DLL and EXE are
same (from same version of C runtime DLL) then there would be no problem which
one is used because they both are same.

I hope I make any sense. It seems to be difficult to write clearly about this
issue without spending whole day in it (the case my boss is not so glad about)

-------------------------------------------------------------
Mika Kurki - System Analyst, ICL Financial Services

to respond remove zzz from start of the address

Interesting.  Whenever we did that (and then subsequently tried to "new" a
piece of memory from one side then "delete" it from the other) it would
either crash with an access violation or report heap management problems
when it shutdown (depending on which one was "newing" and which one was
"deleting")

Was there some setting you used to keep it from getting confused?

--
Reginald Blue                   | Opinions expressed here do not
Natural Language Understanding  | necessarily represent those of
Unisys Corporation              | my employer.
                                |-------------------------------
                                | My email address is wrong, you

Reginald,

 > Was there some setting you used to keep it from getting confused?

I only made very, very sure that only one version of the runtime got
loaded. If, for instance, you use MFC debug DLLs, then you _will_ get
the debug runtime -- in that case, I just go with the flow.

--

Cheers,

Felix.

If you post a reply, kindly refrain from emailing it, too.

No anti-spam address here. Just one comment: IN YOUR FACE!

I think I will have to do so.

10x2all,
Jakob

Reginald Blue schrieb in Nachricht <

Hi Felix,

The Q122675 is definitely a bug which usually affects only C++ DLL's and
not C DLL's.

The problem is with the "delete operator" it calls delete from the DLL space
when
it is supposed to call it from the Application space.

This problem has been fixed in VC 5.0 but still shows up depending on how
you
compile your application (usage of __declspec(dll[im|ex]port).

regards,
-bobby

If your var is an C++ object type and not a scalar type you can give its own
operators new / delete. They are implemented in the same module then and thus
use the same heap manager, debug or non debug mfc and crt etc.
Or you have your object been created with a factory method XXX* CreateXXX();
implemented in and exported from the dll (musn't be inline of course), which
simply calls operator new. If you have more than one creation / deletion point
within your exe and dll, you can provide an additional destruction method void
DeleteXXX(XXX*); in your dll, too, and use only this to methods for creating /
deleting vars which are passed between modules. (Same thing as own new /
delete, but witch global functions instead of methods, so possible for scalar
types too).

Hope this helps.
Andr