Przemek:
>> b) Failure of --thread (--scale) with GPF
>> OS/2-Harbour-OpenWatcom 1.7a was failing in MT with more than one
>>thread
>> I expected it was fixed with 1.8, but no
>> As you may remember, cause was isolated until routines for devices
>>input
>> When you decide we can continue to fix it
>It was a bug in OpenWatcom which was exploited in some calling
>convention when some specific OS2 API functions were used, i.e. some
>mouse and keyboard functions in GTOS2. It was hard to locate the exact
>problem because this bug was corrupting C call stack indirectly and the
> problem was not exploited when the given OS2 API function was executed
> but when Harbour function containing calls to such OS2 API function
>was executed.
>When Maurilio changed some OpenWatcom switches used to control calling
>convention then the problem disappeared. I thought that we are keeping
>these settings but if not then we will have to find them again and
>reactivate.
>It will be necessary to recompile Harbour using different switches.
>First please try to remove -bm.
>If it does not help in next step then please try to use stack calling
>convention instead of register one and change:
> CFLAGS += -5r -fp5
>to:
> CFLAGS += -5s -fp5
>(If you are suing hbmk2 to create final application then you will have
>to sync this switch and change -5r ot -5s in hbmk2.prg[2704]
>If it does not help too then we will have to make some deeper tests.
>Thank you very much.
>In your tests DLMALLOC is also noticeable faster then memory managers
>used by GCC in both versions though on single CPU machine the
>difference is not so huge in MT tests.
>The last thing which we should check is OpenWatcom OS2 build which
>seems to fail with current build switches in MT mode. Can you make
>some tests with different build switches, i.e. using stack calling
>convention instead of register one? (-5r -> -5s)
I tested with Harbour 13017 changing (-5r -> -5s) in os2\watcom.mk and
hbmk2.prg
Failure is the same:
*************************
2009.11.26 06:15:24 OS/2 4.50
Harbour 2.0.0beta3 (Rev. 13017) (MT)+ Open Watcom C++ 12.80.8 (32-bit) x86
THREADS: 2
N_LOOPS: 1000000
1 th. 2 th.
factor
============================================================================SYS1
808:
The process has stopped. The software diagnostic
code (exception code) is 0001.
[E:\harbour911b\harbour\bin\os2\watcom]
[E:\harbour911b\harbour\bin\os2\watcom]help sys1808
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is ***.
EXPLANATION: The program generated an exception that the system cannot
resolve. The soft ware diagnostic code allows determination of what
type of exception was generated.
ACTION: Correct the problem or try a different version of the program.
*************************
About:
"When Maurilio changed some OpenWatcom switches used to control calling
convention then the problem disappeared"
The problem never disappeared. After his tests I explained about
switches and suggested him to review entire messages related to tests
Before we tried with any switch combinations and never resolved. I have
track of it
So we are as we left in December 2008
The proper way is to review those messages to recall tests state,
refresh our minds and then continue with new suggestions
As was and is "hard to locate the exact problem" perhaps we should leave
to resolve after Harbour 2.0 ( Dec 2009, "Harbour Winter 2009 edition" )
but if you want ( and I want ) to resolve immediatly, give me guidelines
:-)
David Macias
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
