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
