Using Compaq Array Visualizer from Delphi .exe, heap management

Using Compaq Array Visualizer from Delphi .exe, heap management

Portrait de Elias Sabbagh

Hi folks!

I have an instance of the Compaq Array Visualizer ActiveX control sitting happily on a Delphi form. I need to get data to it, and I'm using the C API provided in the aview160.dll (suitably linked to my Delphi .exe, of course).

There are constant warnings on the Delphi boards about Delphi's memory sub-allocator and DLLs. Basically, every .exe or .dll compiled with Delphi gets its own heap manager. This means that a Delphi .exe and a Delphi .dll have two seperate heap managers, which will cause corruption in one or both heaps if an allocation happens in the .exe, and the deallocation happens in the .dll. There is a Borland-supplied module (borlandmm.dll) that forces all Delphi-compiled modules to share a singleton sub-allocator, thus avoiding the problem for Delphi-to-Delphi EXEs and DLLs.

I assume that the aglAlloc(), aglMalloc(), aglMallocEx(), and aglFree() routines supplied by aview160.dll allocate memory using their own sub-allocator, perhaps supplied by the C run-time library? If so, might I assume that as long as whatever is allocated on the "Delphi side" is also deallocated there, and whatever is allocated by aglMalloc() is deallocated with aglFree(), then the actual reading and writing to the memory can happen safely on either side of the divide?

I have assumed that this is indeed the case. However, I seem to be running into problems with the aglReshape() call. The third argument to aglReshape is an integer array of dimensions, which I need to dynamically allocate on the Delphi side. Calling aglReshape() never seems to successfuly return. Is aglReshape() somehow reallocating the Delphi memory? This would corrupt the heaps, and be big trouble for me.

Sorry for the long question, and thanks in advance!

Elias Sabbagh

3 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de Community Admin

Hi Elias,

aglMalloc() andaglMallocEx() actually create a shared memory object to store the array data. This allows other processes (e.g. the Array Viewer) to access the data without having to make a copy of the data each time the array is udpated. But as long as you pair aglMalloc() with aglFree() it should work ok.

aglReshape() should just change some header bytes in the memory allocated by aglMalloc(), it won't grow or shrink the memory. i.e. you can use aglReshape to change a one-dimensional 100 element array into a two-dimensional 10x10 element array. So I wouldn't think there could be any danger of aglReshape() corrupting the Delphi heap.

When you call aglReshape() are you sure that agl160.dll is getting a pointer to the first element of thedimensions array? And that Delphi is using 4-byte integers? AV won't hang on to the dimensions array pointer, so you're free to release it once the call completes.

John

Portrait de Elias Sabbagh


John-

I guess that the problem is that my Delphiprototype forthe aglReshape() call isn't correct,because a) Delphi uses 4-byte integers, and b) I'm pretty sure that I'm passing the dynamically-allocated array from Delphi properly. Hmm...

Actually, I'm less sure about part b. There's a bit of fiddling that needs to be done to get the address of the start of the data when dealing with Delphi dynamic arrays, since they're reference-counted, and the count is stored at the front of the object. You can't just pass a pointer to the array; you have to pass a pointer to the 0'th element. Perhaps I've screwed that up...

Anyway, thanks for the glimpse into the internals of the "agl" API.

Elias Sabbagh

Connectez-vous pour laisser un commentaire.