Yeah, that makes some sense. You need to have a matched pair of alloc and
free routines, or you’re going to get problems. Particularly, using a debug
version of one and a non-debug of the other will definitely cause problems,
same with MT or non-MT (MT= Multithread safe).
Of course, all that sort of problem will be solved if the alloc and free
are both in either the DLL or the Application. This also makes sense from a
lot of other perspectives:
- It makes it beautiful
Having matched code looks much neater.
- You encapsulate the way that the memory block is handled from the
application.
The application doesn’t actually need that this is dynamically
allocated, just needs to tell the DLL when it’s finished with it in
general.
- It allows you to change the internal workings of the DLL without having
to recompile and perhaps redesign the application layer.
You may decide to have a caching algorithm, or statically assign a
memory block for the application to use (for example).
- Given a certain amount of foresight when designing the DLL and
application interface, you can even support backwards compatibility between
new DLL and old APP.
That saves you having to update all the applications just because the
DLL is improved, which improves future bugfixes where the APP is correct.
The last one obviously demands some extra work on the DLL design (using
either the size or a version number, for example) to allow it to be
backwards compatible, but it’s entirely possible to do.
–
Mats
-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.
xxxxx@lists.osr.com wrote on 12/03/2004 02:12:53 PM:
Thanks.
FYI, This link says that could happen and why http://mail.gnome.
org/archives/xml/2001-October/msg00080.html
Thanks and Regards
Deepak
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:
xxxxx@lists.osr.com]On Behalf Of Mats PETERSSON
Sent: Friday, December 03, 2004 3:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] free the memory allocated in dll, causes
Invalid Heap Pointer
That should work. You’re probably doing something else wrong.
Single-step through your allocation and make sure that your DLL
function is returning the right thing. If that didn’t work, every
single desktop application would stop working immediately, since the
MFC library used for Visual Studio development will do “new” which
in turn calls the same basic function that “malloc” calls.
Something is wrong either in the DLL or the application.
–
Mats
-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message,
or any action taken by you in reliance on it, is prohibited and may
be unlawful. If you have received this message in error, please
delete it and contact the sender immediately. Thank you.
xxxxx@lists.osr.com wrote on 12/03/2004 10:16:51 AM:
> Hi
>
> Please let me know if someone has a solution for this problem:
>
> Application - 32 bit command line executable.
> DLL - 32 bit with one function that allocates memory using malloc.
>
> Application and DLL build in debug mode.
>
> Application calls the function, gets the memory block and prints the
data.
> On trying to free the memory allocated in dll, causes Invalid Heap
Pointer
> Exception. The reason for the crash is the memory allocated is not in
the
> local address space of the exe.
> If the memory pointer is not accessed, then the free works fine.
>
>
> Thanks and Regards
> Deepak
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> ForwardSourceID:NT000085C6 —
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT0000861A