On Wednesday, 12 November 2014 at 16:10:34 UTC, ketmar via
Digitalmars-d-learn wrote:
On Wed, 12 Nov 2014 16:03:08 +0000
Chris via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:
On Wednesday, 12 November 2014 at 14:42:34 UTC, Chris wrote:
> On Wednesday, 12 November 2014 at 14:26:15 UTC, ketmar via
>> 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.
I've changed the code so that the memory is freed in C.
Although it works "better" it crashes too every now and then
(WindowsError : exception : access violation writing
0x0310A1B4)
Will look into it.
this also can happen due to allocators conflict somehow. or due
to
other code which stores the pointer somewhere and then accesses
the
memory. i think that it will be hard to trace without debugger.
Thanks a million! Just checked it this morning. It was the
latter. I kept a reference to short* data in a class variable in
D and didn't clear that reference when freeing the memory in the
C library.
Interesting though that it never crashes on Linux, only on
Windows did this cause problems.
It is also interesting that core.stdc.stdlib.free() and free() in
the C library produced a slightly different crash behavior. But
that might be down to the fact that the two happen in different
places in the program.
