Sudden Malloc failure

[MartijnHoekstra]

Hi,

A malloc done in a DLL fails at some point in time.
With failing I mean, it hangs. It does not return a pointer, nor does it return NULL. It just hangs.

Situation:
- Application programmed and compiled using VS 6.0. Allows plugin dll's.
- DLL exporting 1 method for the plugin. Compiled in VS 2005.

The DLL malloc's a protocol structure. Within protocol it mallocs a data array.
The application free's the data array and the protocol.

This works fine for the most time 99%. But then almost randomly it starts haning.
The malloc does not return at all, not even NULL.

I am clueless, you?

Cheers,
Martijn

[Alex F]

I think that if Dll makes allocation, it must free this memory itself. Application should call some Dll function, like Release, with pointer allocated by Dll.

[MartijnHoekstra]

I understood that dynamic loading of DLL will make the DLL run in the same memory heap as application.
This should allow a free to be done by application, which I see succeeding 99% of the time.

[Paul McKenzie]

The DLL malloc's a protocol structure. Within protocol it mallocs a data array. The application free's the data array

The only memory that is guaranteed to work this way, regardless of compilers used, compiler settings, etc. where the DLL allocates and the application frees the memory are the OS memory allocation functions such as HeapAlloc, GlobalAlloc, etc.

Functions such as malloc(), realloc(), operator new, etc. are compiler-dependent functions. A malloc() call created using VC 6.0 will not work reliably with a free() call that was created using another version of Visual C++.

The main reason is that the compiler's heap managers are different. If you have a pointer returned by a malloc() call in Visual C++ 6.0, and then you give this pointer to free() that was created with Visual Studio 2005, the heap manager for VC 2005 will have no idea where that pointer came from, but assumes it came from the VC 2005 heap manager. So it looks in the heap manager for this pointer, and either will not use it (since it is invalid), or try to use it and something will happen (crash, seem to work OK, you don't know).

Either you switch to using the OS functions to allocate memory, or you code your DLL so that it is responsible for allocating and freeing the memory.

Regards,

Paul McKenzie

[MartijnHoekstra]

Hi Paul, thanks for the explanation.

What still puzzles me:
- How can it be explained that in most of the time, the "application" is able to free the memory?
- Why dont I see the application hanging on the free(), but on the malloc() instead?
- Why is it hanging anyways?

[hoxsiew]

In the immortal words of the ANSI standard: "The behavior is undefined." It could do anything.

[Paul McKenzie]

Hi Paul, thanks for the explanation.

What still puzzles me:
- How can it be explained that in most of the time, the "application" is able to free the memory?

Maybe the heap managers differ by very little, but that difference triggers the errors. Who knows?

The bottom line is this -- even if it "worked" all the time, it's still wrong. The behaviour is undefined as to what happens when you are using calls that work in pairs (malloc/free, new/delete, etc.), and one half of the pair uses a different version than the other half of the pair.

Imagine if someone was using an old version of some source code you wrote, and mixed it up with a new version of your source code in their application. Wouldn't you expect all kinds of weird things to happen if they start using half the functions from the old version and half from the new version?

Regards,

Paul McKenzie

[originalfamousjohnsmith]

There's not much reason to think that malloc would hang due to different versions. You are probably not using different versions anyway - unless the dll or your code specifically redefined it you are not.

Even if you are, it should be fine unless you allocate with one then free with the other, which won't necessarily ever happen at all. And if it did cause an error it shouldn't be a hang unless there is a bug in malloc itself. Also, I don't think malloc has changed anyway for just this reason. And it's hanging on allocation, not deallocation.

If you put a wrapper around malloc it will probably be easy to see what's happening. Usually hang means failing to release a lock, but it could be a million things. Probably not malloc at all, even if it looks like it. Could be it returns 0 due to no memory and then that causes the error.

[OReubens]

I understood that dynamic loading of DLL will make the DLL run in the same memory heap as application.
This should allow a free to be done by application, which I see succeeding 99% of the time.

Only if the DLL and the process are "hard tied" together. Meaning they're designed to work together and use the SAME version of the C++ runtime.

Since yo'ure saying here they're compiled with differente versions of a compiler, you cannot expect the malloc() of one version of the C++ runtime use by the DLL to be compatible with the free() of another runtime used by the application.


"anything can happen" by ignoring this. Even the fact that seemingly nothing goes wrong at first, but the free's are corrupting the heap of the other runtime. They seem to work, but they're not behaving properly. When doing additional mallocs, the other runtime suddenly encounters data it was never designed to deal with and crashes/hangs.

[originalfamousjohnsmith]

Even if there arre two heaps in play, the heap in the dll won't get corrupted. As far as it's concerned it's just giving out memory it never gets back, and will simply run out of memory after a while. There are ways to ask if memory is in a heap in most systems you can look up but I don't know off the top of my head for VC++ malloc.