Przemek:
Before we tried with any switch combinations and never resolved. I
have track of it
So we are as we left in December 2008
Sorry but now I'm really confused. All what I know about results
of real life OS/2 test comes from you and Maurilio messages.
Now I'm OpenWatcom builds reading that it was never working
correctly in MT mode in whole Harbour history and always fail
in MT mode when second thread accessed GTOS2 function (I guess
that speedtst works correctly with current SVN code when is linked
with GTCGI).
Can you and Maurilio confirm it?
Did it work in the past after modifications in build time switches or
not?
If not then there is no reason to look for old messages.
To be clear. It _was_ hard to locate to exact problem but after your
test I know the exact problem so this part is resolved and it's not
related to Harbour source code at all. The problem is caused by code
generated by OpenWatom for functions which have in their body calls to
some of APIENTRY16 functions like KbdCharIn(). When non main thread
tries to execute such function then it GPFs. It's unimportant how
APIENTRY16 function is used. Important is only the fact that it's
used. I.e. if we have function like:
[...]
Then it will GPF though pGT is always not NULL so KbdCharIn() is never
executed.
Above conclusion is the result of your test done in last year.
So there is only question about finding workaround in OpenWatcom build
configuration to resolve it. Of course if such workaround exists.
I thought that more or less intentionally Maurilio found it and it
was committed to Harbour repository.
These should be switches related to C stack usage i.e. switches to
control calling convention.
It's also possible that we may find some programing workaround,
i.e. using functions to encapsulate calls to APIENTRY16, i.e.
[...]
and then use hb_os2_KbdCharIn() in hb_gt_os2_ReadKey() instead of
KbdCharIn(). It may help because hb_gt_os2_ReadKey() is used indirectly
by pointer to function and maybe only in such situation the OpenWatcom
bug is exploited. But such method is only hack which may not work or
suddenly stop to work in the future due to compile and link time
optimizations, i.e. compiler may automatically inline above function
creating the same code as for initial version.
but if you want ( and I want ) to resolve immediatly, give me
guidelines :-)
If you have some time to make tests then we can try to look for
workarounds for the problem but 1-st I would like to be sure if it
was working in the past and if yes then restore exact build time
switches used for working version to locate the ones which helped
to resolve the problem.
///////
I've reread again old messages and you wrote that the problem can
be resolved by removing -s compile time switch. Can you confirm that
it is still true and if you remove -s from config/os2/watcom.mk[42]
and utils/hbmk2/hbmk2.prg[2706] then MT version of
speedtst --thread
works?
First of all, thanks for your interest
My last message about was Nov 16, 2008, WITHOUT response, so this case
is open since then
Yesterday I read briefly some messages and today deeply all them
As a summary:
- OS/2-Watcom was failing with GPF in MT mode
- Tests lead us to devices input problem (keyboard, mouse, ...) on
threads except 1
- Maurilio made tests changing switchs and it work for him, removing -s
switch
- I made tests with switchs and removing -s switch does not GPF
- But, some tests run slow, freeze, hangs, ...
- ... and here we are
So we faced two problems:
- GPF in MT related to devices input, solved? removing -s
- Slow, freeze, hangs, ..., un-solved yet
A big note:
- Maurilio was using OS/2 SMP kernel
- I was using eComStation 1.2MR, OS/2 4.5, both tested in two machines
This is part of my message after removing -s, as you maybe saw in your
recent review:
--------------------------------------------------
[Harbour] Re: Harbour under OS/2 - OpenWatcom
David Arturo Macias Corona dmacias at mail.udg.mx
Thu Nov 13 09:13:40 EST 2008
>All mttest?? do work (apart from nr. 10) and speedtst works as well.
I rebuilt Harbour with original win32 flags but changed:
-bt=OS2 Platform target
-bm For MT
-s Removed
Except -s remove, rest is equal to all my previous tests
Using hbrun_mt.exe runs
- mttest??.prg, except 9 and 10 due missing functions HB_DBDETACH (9),
HB_GT_STD_DEFAULT (10)
-
[E:\harbour811\harbour\tests]e:\harbour811\ow\bin\hbrun_mt.exe
speedtst.prg --exclude=mem --scale --thread=2
====> Now run without GPF, BUT extremaly slow
Sometimes it seem freezed for very long time
As we can see:
- Remove -s fixed problem with threads except 1
- "-sg" flag for stack grow is unnecessary
I rebuilt Harbour clean with -sg added
Results are the same
[E:\harbour811\harbour\tests]e:\harbour811\ow\bin\hbrun_mtsg.exe
speedtst.prg --exclude=mem --scale --thread=2
run extremaly slow too
Congratulatios for both ( and me ), GPF is solved
Now we have to find why speedtst.prg is so slow, but seem due to
compilers / linker flags too
--------------------------------
and here info about -s for easy remind:
--------------------------
-s flag
=======
Stack overflow checking is omitted from the generated code. By default,
the compiler will emit code at the beginning of every function that
checks for the "stack overflow" condition. This option can be used to
disable this feature. The macro __SW_S will be predefined if "s" is
selected.
--------------------------
and this is part of my last message, without response, which mantain
case open:
--------------------------
[Harbour] Re: Harbour under OS/2 - OpenWatcom
David Arturo Macias Corona dmacias at mail.udg.mx
Sun Nov 16 11:32:22 EST 2008
Definitely speedtst.prg hangs somewhere
I checked OW linker doc,
If not STACK option is used, as OW doc say:
-------------------
"default stack size varies for both 16-bit and protected-mode 32-bit
applications depending on the executable format ..."
-------------------
Entire page for STACK OPTION is below
Removing OP stack=65536 and Using OPTION MAP "default stack size" can be
checked
For hbrun_mt.exe hbrun.map show:
-----------------------------
+-----------------------+
| Linker Statistics |
+-----------------------+
Stack size: 00012000 (73728.)
Memory size: 001db03d (1945661.)
Entry point address: 0002:000bb30e
-----------------------------
So default stack size is greater than previous used ( 73728 > 65536 )
and should be enough
This stack value is used in thread 1, and as limit in thread except 1 if
"-sg" flag is used
As I am not using "-sg" flag, then thread except 1 use fixed value
stated in code using _beginthread()
Testing:
tests\mt\mttest*.prg
********************
Everyone run except 09, 10 due to known missings
speedtst.prg
************
Just MT
Depend of parameters
As exposed before, run extremaly slow and sometimes remain freezed
Entire results are below
hbrun_mt.exe speedtst.prg
=========================
[ total application time: ]...................................258.61
[ total real time: ]..........................................263.15
hbrun_mt.exe speedtst.prg --exclude=mem
=========================
[ total application time: ]...................................103.55
[ total real time: ]..........................................107.36
hbrun_mt.exe speedtst.prg --exclude=mem --scale
=========================
26.3 minutos
[ total application time: ]...................................251.74
[ total real time: ].........................................1578.49
hbrun_mt.exe speedtst.prg --exclude=mem --scale --thread=2
=========================
Remain doing something elsewhere
After 1 hour 40 minutes, I cancelled it
------------------------
[E:\harbour811\harbour\tests]e:\harbour811\ow\bin\hbrun_mt.exe
speedtst.prg --exclude=mem --scale --thread=2
11/16/08 10:18:29 OS/2 4.50
Harbour 1.1.0dev (Rev. 9903) (MT)+ Open Watcom C++ 12.70.8 (32-bit)
THREADS: 2
N_LOOPS: 1000000
excluded tests: 029 030 023 025 027 040 041 043 052 053 019 022 031 032 054
1 th. 2 th.
factor
============================================================================
The external process was cancelled by a Ctrl+Break or another process.
^C
------------------------
I used these linker flags:
LDFLAGS = debug all OP MAP OP CASEEXACT
Obviously some flags for compiler / linker are missing
I checked all "linker directives and options" of OW doc, but many of
them I don not understand
Some one like this can be related
...............................
Formats: OS/2
The "INTERNALRELOCS" option is used with LX format executables under
32-bit OS/2. By default, OS/2 executables do not contain internal
relocation information and OS/2 Dynamic Link Libraries do contain
internal relocation information. This option causes the Open Watcom
Linker to include internal relocation information in OS/2 LX format
executables.
The format of the "INTERNALRELOCS" option (short form "INT") is as follows.
OPTION INTERNALRELOCS
...............................
Przemek, Maurilio:
Review "linker directives and options" of OW doc, perhaps you can find
something related
Przemek: do you have any idea why with "--thread=2" never end ?
Any other suggestions ?
--------------------------
As I said before, I expected this case solved due recent OpenWatcom 1.8
and lots of changes in Harbour
We saw first problem (GPF) remain
So new tests with recent code are necessary
I am doing them and wait for results report
David Macias
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
