On Mon, 13 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
Congratulation for your work.
>> [ One issue is that the app still GPFs on startup
>> when linked with hbvmmt.lib. This is the stack
>> trace according to MSVS2008 debugger: _WinMain()
>> -> hb_vmInit() -> hb_vmProcessDllSymbols() ->
>> hb_vmDo() -> hb_vmTSVarClean() -> hb_vmTSVarClean() ->
>> hb_itemMove(). ]
The callstack seems to be strange. We do not use hb_vmProcessDllSymbols()
at all - it's old obsolete functions.
Also the above calling order is not possible to reach from
Harbour code.
Is it repeatable with other C compiler?
If yest then please try to make MinGW build with -g GCC switch
run you application in gdb ('gdb .\yourapp' and the then 'r' command)
and when it crash show C callstack: 'bt' command).
> Update: According to hb_out.log, the GPF seems to occur
> in my framework .prg code, in INITSTATICS. In this source
> file, quite some (23) THREAD STATICs are declared outside
> the functions. I'm using -gc3 in this source file, and
> Harbour was also compiled with -gc3. App level parts
> of the program are compiled with -gc0.
OK, I've just seen stupid mistake in generating C source
code for thread static and -gc3:
The offset with static thread numbers is taken from 'lPCodePos + ul'
when it should be from: 'lPCodePos + ul + 3'
I'll commit fix in a while.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
