Vendor Library DLL Leaks???

[ahoodin]

I am having a problem with an existing application. There is a cpp/module in the application that takes an instrument reading using a 3rd party IO board. It reads a voltage 1000 times a second and returns an average reading. To do this first a buffer of windows global memory is allocated. There is a handle of type HGLOBAL* that is returned by the function to allocate the buffer.

First a device sends a signal to request a reading. This starts the sample. Periodically inside a thread you check the status of the test. Of course I release the global memory when I close the application.

During the test if you open a new dialog, memory leaks. I know this because: #1 I see that after several hours of unattended operation controls like buttons start to go black or not show up at all. #2 I have tested the instrument reading function with CMemoryState objects and find leaks when I open additional dialogs. #3 After several hours of operation sometimes there is an invalid page-fault at the location of whatever windows control or device context may have been accessesed last.


I am wondering: Does Global windows Memory over-run the application CODE memory space? I am going to update to the next version of the library, but I am wondering if there is any way to move my application memory around so as not to have an overrun. It seems a mistake to allow application memory with data to conflict with the memory used by the application that is running the code. Not very bulletproof architecture.

 

[CoolNameDenied]

The Dialogs themselves may be the problem; don't rule them out.

Are you accessing the HGLOBAL* from the new dialogs? Maybe not relevant, but curious.

Question: Have you tested this in the release version? Sometimes the debugger plays a part in memory leaks, in my experience.

Windows isn't supposed to interfere with your memory... but, in my experience, it sometimes can. The Microsoft Foundation Classes aren't always bulletproof either... What OS are you running under?

More questions than answer, sorry. CoolNameDenied

http://cnd.150m.com

 

[ahoodin]

>The Dialogs themselves may be the problem; don't rule them out.

Well, I havent. Some of the dialogs are actually declared in a global header and shown when initiated modally or non-modally at the appropriate time.

>Are you accessing the HGLOBAL* from the new dialogs? Maybe >not relevant, but curious.

Not directly. The information from the global memory is passed into an array before
it is used.

>Question: Have you tested this in the release version?

>Sometimes the debugger plays a part in memory leaks, in >my experience.

Yes and the debugger seems to be doing its part here.

>Windows isn't supposed to interfere with your memory...

>but, in my experience, it sometimes can. The Microsoft

>Foundation Classes aren't always bulletproof either...

>What OS are you running under?

Well, I believe resource creation functions return a type HGLOBAL. I think that resources may have the same memory scope as the buffer.

Actually the application I am debugging is stuck on W98.

>More questions than answer, sorry.

No sweat.

TX E09,

ahoodin