Przemek:
>> "-s" is used to avoid "stack overflow checking", as OpenWatcom doc
>>state:
>[...]
>I know what it does ;-)
I am in exercise of collect and present info :-)
>it's necessary only for C code calling APIENTRY16 functions.
>In whole Harbour SVN code only in GTOS2 such functions are used.
>If you do not plan to create and compile such C code using hbmk2
>then it's not necessary to modify hbmk2.
OK
>> Tests with gtos2, gtstd, gtcgi lead us to find as conclusion problem
>>is
>> related to "input devices" in threads except 1 (keyboard, mouse, ...)
>> Failed with gtos2, gtstd but not gtcgi
>Please check if using current clean SVN code without any modifications
>you create working speedtst binaries using:
> hbmk2 speedtst -l -kmo -mt -gc3 -gtos2
>to test execute them using:
> speedtst.exe --thread
>This is necessary to confirm that current workaround is working for
>GTOS2.
>Then please rebuild only speedtst using:
> hbmk2 speedtst -l -kmo -mt -gc3 -gtstd
>and repeat:
> speedtst.exe --thread
>if it does not work then we can try to use the same hack for GTSTD
>and check if it help. It will be an answer if it's enough to activate
>debug code to check stack overflow exactly for function which calls
>APIENTRY16 function or it's enough to make it on any upper level.
>This information will be usable in bug report for OpenWatcom users.
>Then I'll try to create small self contain example to exploit the
>problem.
With Harbour 13140:
[E:\harbour911b\harbour\bin\os2\watcom]hbmk2 speedtst -l -kmo -mt -gc3
-gtos2
Harbour 2.0.0beta3 (Rev. 13140)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'speedtst.prg'...
Lines 1204, Functions/Procedures 79
Generating C source output to 'speedtst.c'... Done.
[E:\harbour911b\harbour\bin\os2\watcom]speedtst.exe --thread
[...]
[ total application time: ].....................................0.19
[ total real time: ]...........................................23.47
[E:\harbour911b\harbour\bin\os2\watcom]hbmk2 speedtst -l -kmo -mt -gc3
-gtstd
Harbour 2.0.0beta3 (Rev. 13140)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'speedtst.prg'...
Lines 1204, Functions/Procedures 79
Generating C source output to 'speedtst.c'... Done.
[E:\harbour911b\harbour\bin\os2\watcom]speedtst.exe --thread
2009.12.06 03:56:34 OS/2 4.50
Harbour 2.0.0beta3 (Rev. 13140) (MT)+ Open Watcom C++ 12.80.8 (32-bit) x86
THREADS: all->56
N_LOOPS: 1000000
[ T000: empty loop overhead ]...................................0.00
====================================================================SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 0001.
[E:\harbour911b\harbour\bin\os2\watcom]hbmk2 speedtst -l -kmo -mt -gc3
-gtcgi
Harbour 2.0.0beta3 (Rev. 13140)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'speedtst.prg'...
Lines 1204, Functions/Procedures 79
Generating C source output to 'speedtst.c'... Done.
[E:\harbour911b\harbour\bin\os2\watcom]speedtst.exe --thread
[...]
[ total application time: ].....................................0.39
[ total real time: ]...........................................23.90
As before, gtstd fail with GPF too, and gtcgi does not
>Thank you that you refreshed my mind but now we know more then when
>I wrote above text. I.e. we confirmed it's OW problem and we found
>workaround for it by enabling debug code which checks stack overflow.
>This code more or less indirectly resolves the problem. It's possible
>that it simply initialize some internal OW structures not initialized
>when thread is started so maybe it's enough to call any function
>compiled without -s as workaround. In such case instead of compiling
>GTOS2 with stack debug code we can simply add single function in
>separate
>.obj file which will be executed just after starting new thread. Above
>GTSTD tests can give the basic answer if it's possible or not.
For me we are in same state as in 12-16 November 2008, but with new
Harbour and OpenWatcom and without slow-freeze in MT with "-s" removed
Now we only added selective removing of "-s" in specific places, but
real cause of GPF and solution are un-known yet
For this reason I suggested to review/recall old messages, and to
contact OpenWatcom developers for deeper research
>It doesn't matter. Functionally both make the same.
>It's only important you try clean SVN code without any local
>modifications or HB_* envvar settings.
It was done in this way, thanks
David Macias
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
