Hi Viktor,
In DLLPREPARECALL() GC pointer item is used.
Looks that there is memory leak if when RT error generated
at the end of this function. 'xec' is not freed.
I would like to also suggest one thing. Memory blocks allocated
by hb_gcAlloc() not not attached to any known HB_ITEM and not
locked (hb_gcLock()) will be freed by garbage collector.
This code is potentially danger because RT error handler can
activate GC. It will also block us against adding automatic
GC activation, f.e. inside hb_xgrab() when total allocated
memory reach some limits. If possible please always try to
allocate GC block just before hb_retptrGC() when all initialization
variables are calculated and you do not have to call any other
functions which may internally activate GC in the future.
I know that it's unpleasure condition and I will want to remove it.
I wanted to made this modification after 1.0 but maybe I should
make it now because number of code which uses GC pointers is
growing up really fast.
The modification will be very simple.
hb_gcAlloc() will always return locked block which cannot be freed
by GC. Such block will have to be freed by user (hb_gcFree()) or
attached to known item by one of GC pointer function (f.e.
hb_retptrGC()). Attaching will automatically unlock the GC block.
Such modification in 99.9% will not force code updating and it will
resolve the problem of freeing GC blocks by unexpected GC activation.
Probably it will be also good to make safe such code:
HB_FUNC( F )
{
hb_retptrGC( hb_parptrGC( 1 ) );
}
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
