Crash on Windows with core.stdc.stdlib.free()

[Chris via Digitalmars-d-learn]

On Wednesday, 12 November 2014 at 14:26:15 UTC, ketmar via 
Digitalmars-d-learn wrote:
> On Wed, 12 Nov 2014 14:11:35 +0000
> Chris via Digitalmars-d-learn 
> <digitalmars-d-learn at puremagic.com> wrote:
>
>> On Wednesday, 12 November 2014 at 12:58:19 UTC, ketmar via 
>> Digitalmars-d-learn wrote:
>> > On Wed, 12 Nov 2014 12:40:30 +0000
>> > Chris via Digitalmars-d-learn 
>> > <digitalmars-d-learn at puremagic.com> wrote:
>> >
>> >> The following causes the DLL to crash on Windows:
>> >> 
>> >> Input: immutable(short)* data (immutable because in 
>> >> separate thread).
>> >> // Later
>> >> core.stdc.stdlib.free(cast(short *)data);
>> >> 
>> >> (short* data is provided by the C library, where the memory 
>> >> is allocated)
>> >> 
>> >> On Linux it works fine and never crashes, in the Windows 
>> >> DLL it randomly causes an access violation in memory (both 
>> >> read and write). Note that it doesn't crash immediately, it 
>> >> goes on for a while, but sooner or later it crashes. If I 
>> >> comment out this line, everything works fine. However, if I 
>> >> don't free the memory, I'll have a memory leak. Any 
>> >> hints/advice/guesses?
>> > seems that you are using two different allocators here. one 
>> > is that
>> > comes with DLL and other that comes with D. i bet they 
>> > either using
>> > different runtimes, or C runtime is doesn't know about 
>> > another C
>> > runtime in DLL.
>> >
>> > on GNU/Linux there is only one runtime (most of the time), 
>> > so there
>> > is no problem with different allocators.
>> 
>> That makes a lot of sense. Hm. How can I work around this 
>> problem then? What's involved are a C-dll and a D-dll that 
>> uses the C-dll and is loaded into a Python program. To 
>> complicate things further short* data is passed to C by D. 
>> short* data is then allocated and populated in C.
> if you can extend C DLL, just add wrapper for `free()` there. 
> so you
> will not call `free()` from D, but call C DLL function which 
> will free
> the memory. it's a good practice anyway, 'cause it's 
> recommended to
> free memory in the same library where you allocated it.

I initially had an implementation that did exactly that (I 
usually do that), but for some reason it didn't work properly in 
this particular case and caused all sorts of undefined behavior. 
But I'll have a look at it again.