[REBOL] Re: callbacks
From: lmecir:mbox:vol:cz at: 1-Nov-2007 7:20
Maxim Olivier-Adlhoch napsal(a):
> Hi Ladislav,
>
> yes, I understand the whole issue quite clearly. I know exactly what is
> going on. I was just mentioning, that the [save] option when used in struct
> is akin to half the memory leak of shutting the GC off completely.
>
> in this case, REBOL was trying to free ram for which, it was not the
> original allocator.
>
> IMO it seems the space used for the original struct is being lost somewhere,
> since we are changing its pointer AFTER its been allocated, and telling
> REBOL to not recyle it after.
>
> -MAx
>
Are you telling me, that it is a C routine, which allocates the memory?
If that is so, then Rebol GC isn't likely to deallocate it. My suspicion
is, that something else happens:
1) Your Rebol code allocates some memory and "gives" it to the C library.
2) Your Rebol code "unprotects" the memory it allocated for the C library.
3) The C library fills the memory by some data and gives the memory back
to a callback function.
4) The GC frees the memory.
5) Your callback function accesses the collected memory causing the crash.
If you want to just copy the contents of the memory, then this is the
simplest/fastest way:
memcopy: func [
{copies a region of ram given at address with sizeof length.}
address [integer!]
length [integer!]
/local struct
] [
address: make struct! [address [integer!]] reduce [address]
struct: make struct! compose/deep [s [char-array (length)]] none
change third struct third address
struct/s
]
The advantage of this is, that the memory copy *is* protected, but there
is still a chance, that the GC may release the memory sooner, than the
MEMCOPY function copies it, in which case the crash still may happen.
