On Sat, 07 Nov 2009, Pritpal Bedi wrote: Hi,
> Pritpal Bedi wrote: > > I use something like this code > > > > DO WHILE .t. > > nKey := b_Inkey() > > > > IF nKey != 0 .and. nKey != 1101 // HB_K_RESIZE > > EXIT > > ENDIF > > > > hb_idleState() > > ENDDO > > hb_idleState() was allowing me to release CPU cycles and was > > working perfectly till I last touched Vouch. But of lately I was so > > indulged in HBQT that I simply ignored my product. And so I cannot > > trace back at what point hb_idleState() went crazy. Now it generates > > run-time error refering to > > "Object destructutor failure" > > "Reference to freed block" It happens when object destructor stores reference to freed GC block in some item which is still accessible after releasing inaccessible block. It's also possible that it's result of some memory corruption or mistake in code which manage GC blocks, i.e. some dummy GC hb_gcAllocate(). BTW have you updated your code to not use hb_gcAlloc() but hb_gcAllocate() instead? > To add a note that hb_idleState() works ok with primary thread == 1, > any subsequent thread generates RT error. hb_idleState() is unimportant here. Important is only hb_gcAll() activated inside hb_idleState(). Anyhow the information about threads give me some ideas that what can be source of the problem and it's probably my mistake. I added hb_gtIsGtRef() but it works only for main thread and I forgot to scan all existing HVM stacks and execute this function. If I'm right then it means that tour threads have own GT windows with some GC cargo value or notifier block. In such case as temporary solution you can try to modify src/rtl/hbgtcore.c. Please comment all hb_gcMark() and hb_gcUnlock() calls in this file and check if it resolves the problem. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
