Re: [Harbour] bug?: HBQT: hb_vmRequestReenter() calls without hb_vmRequestRestore()
Hi Viktor Szakáts wrote: I've just checked hbqt_slots.cpp and there are _many_ hb_vmRequestReenter() calls without hb_vmRequestRestore() pairs. I don't know the consequences, but it doesn't seem right. Matched. I also do not know its implications, Przemek ? 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-tp26685232p26686367.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
Re: [Harbour] bug?: HBQT: hb_vmRequestReenter() calls without hb_vmRequestRestore()
On Mon, 07 Dec 2009, Pritpal Bedi wrote: Hi, I've just checked hbqt_slots.cpp and there are _many_ hb_vmRequestReenter() calls without hb_vmRequestRestore() pairs. I don't know the consequences, but it doesn't seem right. Matched. I also do not know its implications, Przemek ? 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. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bug?: HBQT: hb_vmRequestReenter() calls without hb_vmRequestRestore()
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
Re: [Harbour] bug?: HBQT: hb_vmRequestReenter() calls without hb_vmRequestRestore()
On Mon, 07 Dec 2009, Pritpal Bedi wrote: Hi 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. Without deep code analyzing I cannot precisely answer but after short looking at hbqt_slots.cpp I do not think so. Missing hb_vmRequestRestore() can increase HVM stack a little bit but only to some fixed value which is rather small in comparison to total memory usage so I do not think so. Should we use these calls or not ? You should. The above text was only about side effects created by wrong usage of hb_vmRequestReenter() without hb_vmRequestRestore() and I hope that know will create any code which depends on that side effects because they may change in the future. I.e. we can add code to generate RT or internal error if hb_vmRequestReenter() does not have corresponding hb_vmRequestRestore(). best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
