So how about removing -s switch altogether for watcom/os2 in both our make system and hbmk2?
For the reason that a slightly slower, but working app is better than a failing app. Brgds, Viktor On 2009 Dec 6, at 11:26, David Arturo Macias Corona wrote: > 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) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
