On Tue, 18 May 2010, Mindaugas Kavaliauskas wrote:
Hi,
> >This is expected and documented few times on this list behavior.
> >Of course it's a bug but it cannot be well fixed without very serious
> >modifications in RDD code and all code (also 3-rd part one) which
> >access any RDD methods.
> >It's necessary to introduce sth like:
> > pArea = hb_rddLockCurrentArea();
> > [...] // any RDD methods
> > hb_rddFreeArea( pArea );
> >hb_rddLockCurrentArea()/hb_rddLockArea(iArea) will increase
> >reference counter and hb_rddFreeArea() will decrease it.
> >non zero reference counter will delay releasing the pArea
> >structure until hb_rddFreeArea() will set it to 0.
> Thank You. I though it could something like:
> 2010-03-15 14:04 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> * harbour/src/rdd/dbfcdx/dbfcdx1.c
> ! fixed bad copy and past typo which could cause internal error when
> new index using existing order (subindex) was created without
> ADDITIVE
> clause. Bug reported by Mindaugas - many thanks for the information.
> because we found this bug in a similar way in the same project.
Not this time. We do not have any protection against closing WA
from any user code (i.e. key/for/filter/relation expressions or
from error handler) when it's used by RDD code :-(
Anyhow looking at your example I can see that one of them generates
internal error due to illegal value returned by error block.
This is also expected and Clipper compatible behavior.
Here is reduced example you can test also in Clipper:
PROC MAIN()
ErrorBlock( {|| NIL } )
BEGIN SEQUENCE
? array(0)[1]
END SEQUENCE
RETURN
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
