Hi

Przemysław Czerpak wrote:
> 
> It may change in different HVM version so no one should create code
> which depends on current behavior anyhow if you are interested what
> happens now then return value is overwritten by last return value in
> executed code (depending on context it may cause some serious runtime
> problems (Pritpal should remember problems with runtime errors due to
> overloaded returned logical value in xHarbour) and the exception (QUIT,
> BREAK, ENDPROC) is not properly restored. Additionally stack items
> allocated for stored data are not freed until returning to upper level
> HB_FUNC which activated such C code so executing hb_vmRequestReenter()
> without hb_vmRequestRestore() in a loop increase the stack size. We
> have automatic stack resizing so it will not generate any visible
> error until system has enough memory but of course resources are
> consumed.
> 

May be this gives a clue towards memory consumption 
which was keeping growing. Actually hb_vmRequestReenter()
was being called unmatched with hb_vmRequestRestore() in 
all the slots handelling code.

Should we use these calls or not ?

Regards
Pritpal Bedi
-- 
View this message in context: 
http://old.nabble.com/bug-%3A-HBQT%3A-hb_vmRequestReenter%28%29-calls-without-hb_vmRequestRestore%28%29-tp26685232p26687237.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to