On Fri, 27 Mar 2009, Angel Pais wrote: Hi,
> It GPF'd with this log: > FATAL ERROR LOG > Not recoverable Error! > SYS Thread-ID: 1224 > Module: MOM > Error Codes: EH: 1006 Sub: 0(0) OS: 0 XPP: 15 > Call Stack of Thread 1 (1732): > @notif...@i@SUBSCRIBE(0) > HB_MUTEXSUBSCRIBE(0) > TEST(0) > MAIN(0) > Call Stack of Thread 2 (1548): > Call Stack of Thread 3 (1224): > T044(0) > THTESTSCALE(0) > Call Stack of Thread 4 (1180): > T044(0) > THTESTSCALE(0) > File: C:\experimentos\speedhb\speedxpp.exe > TimeStamp: 20090327 15:52 > End of FATAL ERROR LOG. And you are not alone with such results. Looks that xbase++ is not MT safe in some basic tests. I have information that in randomly GPFs in T023 or T044 on different computers. You can try to exploit it by: speedtst --thread=2 --scale --only=023,044 Please try to repeat above tests few time on different machines. It's also possible that the problem is not exactly in this tests but somewhere else anyhow definitely there is sth wrong. It's a very serious problem which should be reported to xbase++ authors. I wanted to test the automatic item write protection in xbase++ in some unpleasure to protect situations but looks that it fails internally in places which should not cause any problems so any more advanced tests with this language does not make sense until basic MT functionality will not be fixed. It also causes that it's hard to say something about xbase++ MT solutions. I do not know xbase++ code and I can only guess some things using information from tests and some necessary and enough conditions which have to be passed to make MT programs safe. But when xabse++ crashes like above then it means that some fundamental conditions I'm using are false. I think that xbase++ users should report this problem to some xbase++ support list with speedtst code as example. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
