Przemek:
>And this is the confirmation I was asking for.
>Thank you very much for you help and all tests.
>Now I can write self contain example which illustrates the problem.
>I want to create two ones. The first one will allways fail exploiting
>the problem inside OW CRTL and the scond one will
On Tue, 08 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> I expected not to fail in gtos2 and gtstd, but as gtstd failed, I
> checked files and made confirmations to be sure, and at last I added
> "config\os2\watcom.mk" content in message for clarity
Thank you very much.
> >It also means tha
Przemek:
config\os2\watcom.mk contain:
ifeq ($(filter $(LIBNAME),gtos2 gtstd),)
CFLAGS += -s
endif
Have you made clean Harbour build?
Yes, of course
I expected not to fail in gtos2 and gtstd, but as gtstd failed, I
checked files and made confirmations to be sure, and at last I a
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> > I do not see any reason to break using GTOS2 in MT mode waiting for
> > OpenWatcom fix so I would like to keep current hack until it will
> > not be fixed in OW.
> In your prev mail you told that full removal
> of -s also doesn't help on watcom
>> Okay, that clears it up. So in essence OpenWatcom for OS/2
>> is broken whatever we do in Harbour.
>> [ In this case though, we may safely readd -s for all modules,
>> thus deleting our little hack and wait for Watcom team to fix it. ]
>
> I do not see any reason to break using GTOS2 in MT mod
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> Okay, that clears it up. So in essence OpenWatcom for OS/2
> is broken whatever we do in Harbour.
> [ In this case though, we may safely readd -s for all modules,
> thus deleting our little hack and wait for Watcom team to fix it. ]
I do not see
>> I've just seen David's latest tests... IMO if there
>> is no reasonable solution for it, removing -s could
>> still be a fallback option, for the reason that
>> watcom/os2 is not a primary target, I mean no one
>> seems to use it for production, in practice we need it
>> only for cross-plat
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> I've just seen David's latest tests... IMO if there
> is no reasonable solution for it, removing -s could
> still be a fallback option, for the reason that
> watcom/os2 is not a primary target, I mean no one
> seems to use it for production, in
On Mon, 07 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> Harbour 13153
> config\os2\watcom.mk contain:
>ifeq ($(filter $(LIBNAME),gtos2 gtstd),)
> CFLAGS += -s
>endif
Have you made clean Harbour build?
> [E:\harbour911b\harbour\bin\os2\watcom]hbmk2 speedtst -l -kmo -mt
> -gc3
>> So how about removing -s switch altogether for watcom/os2
>> in both our make system and hbmk2?
>
> No. It's not necessary to touch hbmk2.
>
>> For the reason that a slightly slower, but working app is
>> better than a failing app.
>
> This slight slower means over 3 times slower.
> -s disa
Przemek:
>We only do not know the exact place but this is a job for OpenWatcom
>developers to fix it. I do not plan to make it myself. Anyhow we can
>make some other tests to reduce the problem yet and better tune final
>self contain example which can be used in bug report.
>I do not see anythi
On Sun, 06 Dec 2009, Szak�ts Viktor wrote:
Hi,
> So how about removing -s switch altogether for watcom/os2
> in both our make system and hbmk2?
No. It's not necessary to touch hbmk2.
> For the reason that a slightly slower, but working app is
> better than a failing app.
This slight slower m
On Sun, 06 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> 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 120
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 "
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 u
On Sat, 05 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> "-s" is used to avoid "stack overflow checking", as OpenWatcom doc state:
[...]
I know what it does ;-)
> I am unsure if switchs changes must be managed in hbmk2.prg too
it's necessary only for C code calling APIENTRY16 functions.
In
>> linked with GTSTD, i.e.:
>> hbmk2 speedtst.prg -l -kmo -gc3 -gtstd
>> Such information may be important for OpenWatcom developers.
>
> Harbour 13130 or 13131 ?
They are currently equivalent.
Brgds,
Viktor
___
Harbour mailing list (attachment size
Przemek:
Harbour code does not make any difference in this problem.
It's only OpenWatcom bug.
So the only one solution is removing -s option.
In such case we have to find the method to pass information from
src/rtl/gtos2/Makefile to config/os2/watcom.mk that -s should not
be used. I can quite
On Sat, 05 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> From previous tests only -s removed avoid GPF
> A year ago -sg increased run time, but today we have new Harbour and new
> OpenWatcom
Harbour code does not make any difference in this problem.
It's only OpenWatcom bug.
So the only one
Przemek:
HB_BUILD_OPTIM := no
Thank you very much. This is what I wanted to see :-)
So all what we have to do is finding/adding method to disable
only -s switch when GTOS2 is compiled by OpenWatcom.
HB_BUILD_OPTIM := no disables all optimizations so we need
something more selective here.
On Wed, 02 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> Now below are tests with only src\rtl\gtos2\Makefile adding:
> HB_BUILD_OPTIM := no
> Tests with
> speedtst.exe --thread ...
> does not fail with GPF
Thank you very much. This is what I wanted to see :-)
So all what we have to do i
Przemek:
Did you checked message included below ?
As additional note, I tried to build current Harbour using OpenWatcom
1.7a in place of 1.8 and it fail to compile hbsha2.c
But we can forget OpenWatcom 1.7a
I updated results included below with a third computer:
Sempron 3000+, 1800 MHz, 128
Przemek:
Yes, I want you add it to src/rtl/gtos2/Makefile at line 5
Sorry, I confused "add" with "change"
I used:
set HB_BUILD_OPTIM=no
and what you have recompiled later and how?
Sorry that I'm asking but I have to be sure what exactly was done.
Many thanks for your tests.
Fresh SVN,
On Tue, 01 Dec 2009, David Arturo Macias Corona wrote:
Hi,
> >Thank you very much. So now we know that we can remove -s as
> >workaround. Unfortunately it causes very big speed overhead. Much
> >bigger then in Linux where removing -s reduce the speed only ~24
> >percent. It's 363% what is even bi
Przemek:
I have not seen response
David Macias
Przemek:
I know but the problem seems to be inside OpenWatcom code and for me it
looks like OpenWatcom bug which probably can be quite easy fixed but
I need more information to be sure.
///
Thank you very much. So now we know that we can rem
Przemek:
I know but the problem seems to be inside OpenWatcom code and for me it
looks like OpenWatcom bug which probably can be quite easy fixed but
I need more information to be sure.
///
Thank you very much. So now we know that we can remove -s as
workaround. Unfortunately it causes very
Przemek:
I brought back to life my computer Athlon XP 2400+ used in tests in
Oct-Dec 2008, mainly for:
- Confirm if failures are due to brand/processor architecture
- How it compare with current status/tests
and remember:
-
So we faced two problems:
- GPF in MT rel
On Fri, 27 Nov 2009, David Arturo Macias Corona wrote:
Hi,
> Here is the summary
> If you want detailed results for each case let me know
> Harbour 13035
> OpenWatcom 1.8
> Below are results using:
>
>hbmk2 -m -n -w -es2 -l -kmo -gc3 speedtst.prg
> speedtst.exe
On Fri, 27 Nov 2009, David Arturo Macias Corona wrote:
Hi,
> 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
Exactly.
> - Maurilio made tests changing switchs and it work for him, removing -s
>
Przemek:
>So new tests with recent code are necessary
>I am doing them and wait for results report
and remember:
-
>So we faced two problems:
>- GPF in MT related to devices input, solved? removing -s
>- Slow, freeze, hangs, ..., un-solved yet
>A big note:
>- Maurili
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
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 O
On Fri, 14 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> I did one more test and I've found that -bm has a great impact, on memory
> mostly, speedtst ST:
> T029 with -bm 22 sec.
> T030 with -bm 25 sec.
> T029 w/o -bm 1.6 sec.
> T030 w/o -bm 2.0 sec.
Exactly. It has horrible performance impact w
Maurilio:
>The "bm" option must be specified since we are creating a multi-threaded
>application. If your multi-threaded application contains more than one
>module, each module must be compiled using the "bm" switch.
>So, it is not enough to buil hbvmmt with bm but all libs, but, doing
so, >wha
I did one more test and I've found that -bm has a great impact, on memory
mostly, speedtst ST:
T029 with -bm 22 sec.
T030 with -bm 25 sec.
T029 w/o -bm 1.6 sec.
T030 w/o -bm 2.0 sec.
Best regards.
Maurilio.
PS. speedtst MT takes nearly twice.
Maurilio Longo wrote:
> Przemyslaw, David,
>
> B
Przemyslaw, David,
BTW, from watcom docs I read:
The "bm" option must be specified since we are creating a multi-threaded
application. If your multi-threaded application contains more than one module,
each module must be compiled using the "bm" switch.
So, it is not enough to buil hbvmmt with bm
Przemyslaw, David,
David Arturo Macias Corona wrote:
>
> We can ignore -5[r], -fp5, -6[r], -fp6
>
I did some tests this morning, passing from no options to -6r -6fp changes
speedtst ST time from 16.8 to 16.6 seconds, so they're worth nothing.
> You are missing -bm for MT
>
I've not used it and
On Thu, 13 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Not.
> -bt should be present
> Which I removed was osn, value used in message:
> "creating a (osn) executable"
> by default is OS/2
OK.
> >> changed -5 to -5r because -5 is for 16bit code.
> >I think it does not cause any diff
Przemek:
>Just like David. He also removed -bt
Not.
-bt should be present
Which I removed was osn, value used in message:
"creating a (osn) executable"
by default is OS/2
>> changed -5 to -5r because -5 is for 16bit code.
>I think it does not cause any difference when wpp386 is used but of
>
On Thu, 13 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> I'think I've found something:
> first of all, I started from config/win32/owatcom flags, then I had to remove
> -bt=OS2 which is wrong, should be -bt=OS2V2 but this gives an undefined
> function referenced error when building, so I removed
Przemek, Maurilio:
I checked all compiler flags info and for us just -s is critical, rest
are mainly default values
Without -s MT run fine, including "speedtst.prg --scale" which based on
my tests revealed problem with threads except 1
-s seem to be the end of a week plenty of tests :-)
>I'th
Przemyslaw,
I'think I've found something:
first of all, I started from config/win32/owatcom flags, then I had to remove
-bt=OS2 which is wrong, should be -bt=OS2V2 but this gives an undefined
function referenced error when building, so I removed every thing, then I
changed -5 to -5r because -5 is
On Wed, 12 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> I think the problem is not in the code but in the flags used to build harbour,
> I've changed owatcom.cf this way
It's highly possible.
> I've removed nearly all compilation flags, I don't know what they mean, but
> anyway, I've always t
Checked with an older version OS/2 MCP (Media Convenience Pack) which
have his own environment, so eCS paths, sets, files, libraries, dlls ...
are excluded
Same failures as in eCS 1.2MR
Using hbrun_mt.exe from eCS in OS/2 MCP
[E:\harbour811\harbour\tests]e:\harbour811\ow\b
>I think the problem is not in the code but in the flags used to build
>harbour, I've changed owatcom.cf this way
>#CPPFLAGS = -j -w3 -d2 -5s -5r -fp5 -oxehtz -zq -zt0 -mf -bt=NT
>#DAVID: CPPFLAGS = -w2 -d1 -zq -bt=OS2
>CPPFLAGS = -w2 -d1 -zq -bt=OS2 -bm
>#architecture flags
>#CPPFLAGS += -5 -fp
Przemyslaw, David,
I think the problem is not in the code but in the flags used to build harbour,
I've changed owatcom.cf this way
#CPPFLAGS = -j -w3 -d2 -5s -5r -fp5 -oxehtz -zq -zt0 -mf -bt=NT
#DAVID: CPPFLAGS = -w2 -d1 -zq -bt=OS2
CPPFLAGS = -w2 -d1 -zq -bt=OS2 -bm
#architecture flags
#CPPFLA
On Tue, 11 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> what do you use to build harbour with watcom?
> On my pc, simply trying to build a single .c file from the ide gives a trap
> inside OS2KRNL, so I fear it is not SMP ready.
I do not know if the IDE is SMP ready but it's not a problem for
On Tue, 11 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> GCC has this code inside libos2 which is linked with every program:
> ---8<
> /* kbd4.c */
> #define INCL_KBD
> #include
> USHORT _THUNK_FUNCTION (Kbd16CharIn) ();
> USHORT KbdCharIn (PKBDKEYINFO pkbci, USHORT
On Tue, 11 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> I don't know, but I remember that I started working on harbour for OS/2
> exactly for the same problem, sometimes it was GPFing without reason and I
> traced that reason to two things:
> 1) KBD code not using tiled memory
> 2) gtos2.c code
Maurilio:
>Anyway, this code works ok when built using GCC:
>function main()
> hb_threadStart( @t() )
> inkey(100)
>return
>function t()
>local n := 10
>while n-- > 0
> inkey( 1 )
>enddo
>return
That code work fine with gcc335 here
With OpenWatcom
---
Przemyslaw,
GCC has this code inside libos2 which is linked with every program:
---8<
/* kbd4.c */
#define INCL_KBD
#include
USHORT _THUNK_FUNCTION (Kbd16CharIn) ();
USHORT KbdCharIn (PKBDKEYINFO pkbci, USHORT fWait, HKBD hkbd)
{
return ((USHORT)
(_THUN
David,
what do you use to build harbour with watcom?
On my pc, simply trying to build a single .c file from the ide gives a trap
inside OS2KRNL, so I fear it is not SMP ready.
Maurilio.
David Arturo Macias Corona wrote:
> Przemek:
>
>>So it's general problem with accessing console from other t
Przemyslaw,
> To be precise the problem is with any console input and it's inside pure
> OS2 API functions. It means that we probably using them in wrong way.
I attach here kbCharIn docs
-8<--
Reads a character data record from the keyboard.
#define INCL_KBD
#include
PKBD
On Tue, 11 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Przemek:
> any comments ?
Thanks for the example but it does not help us in the problem we have.
> I found in documentation included in OW a sample for multithreading
> Entirely page is below
> Przemek, can you check page ?
> Th
On Tue, 11 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Do you have answer about this ?
But was it the question?
> I do not know if it is what you are looking for
> I found in different places of documentation included in OW
> -
> The macro _threadid can be used to determine
Przemek:
>So it's general problem with accessing console from other threads.
>To be precise it's KbdPeek() and kbhit() is probably simple wrapper to
>it.
>It means that OW internals are also effected by this problem.
>The question is if it can be resolved or not. Is it OW bug or problem
>with
Przemek:
any comments ?
David Macias
I found in documentation included in OW a sample for multithreading
Entirely page is below
Przemek, can you check page ?
They talk about DosEnterCritSec() and DosExitCritSec() to prevent
collisions between threads
I tested using
wcl386 -bt=os2 -bm -l=o
Przemek:
Do you have answer about this ?
David Macias
[Przemek]
../../thread.c(1240): Error! E029: col(60) symbol '_gettid' has not
been declared
_gettid() is GCC local function.
I do not see function which returns directly thread ID in OS2 API.
Probably it can be extracted from TIB struct
On Mon, 10 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> It seems you did focus on mouse code, I've never dealt with it, but I'd say it
> has to do with openwatcom, because with GCC mttest*.* work ok.
To be precise the problem is with any console input and it's inside pure
OS2 API functions. It
David, Przemyslaw,
I'm sorry, I was not monitoring this list lately because of lack of spare
time, anyway, can I do to help?
It seems you did focus on mouse code, I've never dealt with it, but I'd say it
has to do with openwatcom, because with GCC mttest*.* work ok.
If I'm not wrong, openwatcom
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Good question but I am not tested that
> What I say is: using gtos2, at least in these tests, screen/output is not
> refreshed and tracing labels existent in body of fuction where error happen
> are not shown
> You will see more
I found in documentation included in OW a sample for multithreading
Entirely page is below
Przemek, can you check page ?
They talk about DosEnterCritSec() and DosExitCritSec() to prevent
collisions between threads
I tested using
wcl386 -bt=os2 -bm -l=os2v2 mthread
and results are:
[Przemek]
> ../../thread.c(1240): Error! E029: col(60) symbol '_gettid' has not
been declared
>
> _gettid() is GCC local function.
> I do not see function which returns directly thread ID in OS2 API.
> Probably it can be extracted from TIB structure returned by
> DosGetInfoBlocks(). I cannot fin
>> is executed but screen is not refreshed with tracing labels on it
>> I was catching and error DISAPPEAR applying in hb_gt_os2_ReadKey():
>>/* KbdCharIn( s_key, IO_NOWAIT, ( HKBD ) * s_hk ); */
>> As you said, fail reading keyboard input except thread 1 :-)
>we will have to find why it h
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Results included in message were redirected to saleos2.txt, salecgi.txt,
> salestd.txt
> In screen or redirected are same
> Entire results are below
> It work correctly using hb_gt_cgi_ReadKey() as hb_gt_os2_ReadKey()
> I insist,
>Thank you very much.
>Maybe when GTOS2 is used then screen is not refreshed before crach.
>Do you have the same results when you redirect application output
>to file? f.e.:
> pba.exe > out.log
Results included in message were redirected to saleos2.txt, salecgi.txt,
salestd.txt
In screen or
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Entire results for HB_GT_OS2_DEFAULT, HB_GT_CGI_DEFAULT, HB_GT_STD_DEFAULT
> are below
> HB_GT_OS2_DEFAULT and HB_GT_STD_DEFAULT should fail equal, but STD does a
> step ahead (??)
Thank you very much.
Maybe when GTOS2 is used
>You set it too early. It will cause that harbour.exe will
>also create trace.log :-)
>It's not a problem because it will be overwritten by
>test application.
You are right
>> 9/11/08 7:29a 143,326 0 a--- trace.log
>And this is correct log from pba2.exe
>> 9/11/08 7:33a
Based in your explanation, fails trying to execute
iKey = HB_GTSELF_READKEY( pGT, INKEY_ALL );
---> hb_gt_os2_ReadKey()
but never execute it
Second thread can not access this "low level GT driver READKEY()
method (
GTOS2:hb_gt_os2_ReadKey() ) ?
What is very strange and should not happen.
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Original message is included below
>
> As summary:
>
> For first thread (how do you know is 1 ? ):
> -
> [...]
> 2. hb_threadMutexLock()
> 2. hb_inkeyPoll()
> 3. hb_inkeyPoll()
> 1. hb_gt_os2_ReadKey()<---
> 2. hb_
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> I made a Harbour fresh checkout and build with
> set C_USR=-DHB_FM_STATISTICS_OFF -DHB_TR_LEVEL_DEBUG
> Screen output (same as Win32:OW):
>
> make[3]: *** [hboutdbg.obj] Error 8
> make[2]: *** [descend] Erro
Viktor:
>> Screen output (same as Win32:OW):
>>
>> make[3]: *** [hboutdbg.obj] Error 8
>> make[2]: *** [descend] Error 2
>>
>What is the error message?
wpp386 -DHB_FM_STATISTICS_OFF -DHB_TR_LEVEL_DEBUG ../../hboutdbg.c
-fo=hboutdbg.obj
../../hboutd
> It will resolve possible GPF during MT tracing but it will
> have no effect on creating trace.log.
> If it was not created in your builds then it means that sth is
> wrong. Maybe you used different libraries which were compiler
> without C_USR flag or test application was not recompiled.
Fresh
Hi David,
Screen output (same as Win32:OW):
make[3]: *** [hboutdbg.obj] Error 8
make[2]: *** [descend] Error 2
What is the error message?
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
h
I made a Harbour fresh checkout and build with
set C_USR=-DHB_FM_STATISTICS_OFF -DHB_TR_LEVEL_DEBUG
Screen output (same as Win32:OW):
make[3]: *** [hboutdbg.obj] Error 8
make[2]: *** [descend] Error 2
Surprise: sqlite3 show a lot of warnings in gcc335,
On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> I have not updated Harbour code from SVN trying to not introduce a
> different behaviour by some recent change
> But perhaps is time to use a fresh checkout and recreate tests
> I will do that
It will resolve possible GPF during
>> So Harbour tracing fails in MT / OW
>I do not know what is wrong in this build but there is no
>difference between MT and ST mode in such tests. Both should
>create tracelog. I've just tested it and it works. Though
>I've found one problem. Some tracelog message in memvars.c can
>cause GPF. I'
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Rebuilt Harbour with
> set C_USR=-DHB_FM_STATISTICS_OFF -DHB_TR_LEVEL_DEBUG
> Before running new test application (pba.exe):
> set HB_TR_LEVEL=HB_TR_DEBUG
> set HB_TR_FLUSH=1
> set HB_TR_OUTPUT=trace.log
> and results are:
>So it will crashes inside hb_vmExecute()
>Please try to commenct line 1127 in hvm.c
> hb_inkeyPoll();
>to eliminate yet another possibly danger place and make test.
>
>Farther tracing using this methods will not be effective.
>hb_vmExecute() operates on too many functions.
>It will be nec
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> hb_gt_os2_ReadKey() is working fine, but it happen many steps before error.
Where did you found such information?
> I marked it to you in tracing list (you skiped it, review it)
> TID=1
> 2. hb_threadMutexLock()
> 2. hb_inkeyPo
>And here it should execute hb_gt_os2_ReadKey().
>Strange that we do not see "1. hb_gt_os2_ReadKey()" on the screen.
>Maybe the message is overloaded by sth?
>Please add at the begining of hb_gt_os2_ReadKey() before:
> HB_TRACE(HB_TR_DEBUG, ("hb_gt_os2_ReadKey(%p,%d)", pGT, iEventMask));
>this
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Some pass in:
>iKey = HB_GTSELF_READKEY( pGT, INKEY_ALL );
> I put tracing in
> static int hb_gt_def_ReadKey( PHB_GT pGT, int iEventMask )
> and
> static int hb_gt_def_MouseReadKey( PHB_GT pGT, int iEventMask )
> but never a
So it fails before hb_gt_os2_ReadKey().
Let's check all steps.
HB_GTSELF_INKEYPOLL( pGT ) executes hb_gt_def_InkeyPoll() from
hbgtcore.c. Then hb_gt_def_InkeyPollDo() is called which calls
iKey = HB_GTSELF_READKEY( pGT, INKEY_ALL );
Please change hb_gt_def_InkeyPoll() and hb_gt_def_InkeyPollD
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> I corrected your C code :-)
:-) I'm writing it by hand in this messages only using mouse for
copy and past and here I marked " in function name. It's possible
that sth like that will happen, sorry.
> Some pass in:
>iKey = H
>So it fails before hb_gt_os2_ReadKey().
>Let's check all steps.
>HB_GTSELF_INKEYPOLL( pGT ) executes hb_gt_def_InkeyPoll() from
>hbgtcore.c. Then hb_gt_def_InkeyPollDo() is called which calls
> iKey = HB_GTSELF_READKEY( pGT, INKEY_ALL );
>Please change hb_gt_def_InkeyPoll() and hb_gt_def_Inkey
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David.
> Did you see this info in gtos2.c about 16 bit ?
> -
> * Copyright 2000 - 2001 Maurilio Longo <[EMAIL PROTECTED]>
> *hb_gt_DispBegin() / hb_gt_DispEnd()
> *hb_gt_ScreenPtr() and hb_gt_x() functions and vi
If you will have problems with tracing then please tests
code below. It's rtl/gtos2/gtos2.c hb_gt_os2_ReadKey()
replacement.
Could affect something (gtos2.c) ?
#if defined(HB_OS_OS2_GCC)
/* 25/03/2000 - [EMAIL PROTECTED]
OS/2 GCC hasn't got ToolKit headers available */
#include
#else
If you will have problems with tracing then please tests
code below. It's rtl/gtos2/gtos2.c hb_gt_os2_ReadKey()
replacement.
[...]
>As you can see with GTCGI it's related to GT.
>Looks like it's caused by keyboard related functions when
>executed from non main thread.
>> Not tested yet with yo
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Not yet with hope to find problem with these tests
Now we are nearly in the place.
> I think error will happen with any gt
> hbrun_mt.exe is gtos2 and current .prg for tests is gtstd
As you can see with GTCGI it's related to GT
>In some pass of:
> HB_GTSELF_INKEYPOLL( pGT );
We have:
#define HB_GTSELF_INKEYPOLL(g)
(g)->pFuncTable->InkeyPoll(g)
>The mutex locking is correct.
>Next candidate are GTOS2 internals.
>BTW have you tried to enable tracing?
>It would help us to locate the problem quite fast.
Not yet with h
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> 2. hb_threadMutexLock()
> 2. hb_inkeyPoll()
> 3. hb_inkeyPoll()
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
Try to check hb_gt_os2_ReadKey().
In the .prg test code I sent was:
announc
On Sat, 08 Nov 2008, Przemyslaw Czerpak wrote:
Hi David,
> The mutex locking is correct.
> Next candidate are GTOS2 internals.
> BTW have you tried to enable tracing?
> It would help us to locate the problem quite fast.
If you will have problems with tracing then please tests
code below. It's rt
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> 1. hb_threadMutexLock()
> _hb_gettid()
> TID=2
> _hb_gettid()
> TID=2
> 2. hb_threadMutexLock()
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
The mutex locking is correct.
Next candidate ar
I used:
HB_EXPORT void hb_inkeyPoll( void )
{
PHB_GT pGT;
HB_TRACE( HB_TR_DEBUG, ("hb_inkeyPoll()") );
printf("1. hb_inkeyPoll()\r\n");fflush(stdout);
pGT = hb_gt_Base();
printf("2. hb_inkeyPoll()\r\n");fflush(stdout);
if( pGT )
{
printf("3. hb_inkeyPoll()\r\n");fflus
>So it's not exactly inside _hb_gettid(). Good I was afraid that
>we will have to look for workaround to this function.
>Let's check the whole mutex lock function.
>I added 2 printf() calls to this function.
[...]
Error happen
Using -bm flag and hbvmmt
-
_hb_gettid()
TID=1
1. h
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
> Error happen
> -
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=1
> _hb_gettid()
> TID=2
> _hb_gettid()
> TID=2
>
Please change it a little bit yet.
>ULONG _hb_gettid( void )
>{
> ULONG tid = 0;
> PTIB ptib = NULL;
>
> printf( "_hb_gettid()\r\n", tid ); fflush(stdout);
> if( DosGetInfoBlocks( &ptib, NULL ) == NO_ERROR )
> {
> if( ! ptib )
> { printf( "ptib is NULL\r\n" ); fflush(stdo
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> To see something I added last tracing label
> -
> ULONG _hb_gettid( void )
> {
>ULONG tid = 0;
>PTIB ptib = NULL;
>
>if( DosGetInfoBlocks( &ptib, NULL ) == NO_ERROR )
>{
> if( ! ptib
>And we've got a reason. I expected that it will be exploited earlier
>by hb_gtAttach() but I forgot that when GT is inherited attaching is
>done without locks.
>Looks that it fails inside _hb_gettid() when it's executed from non
>main thread but I only guess now.
>Please restore original hvm.c an
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> >So it will crashes inside hb_vmExecute()
> >Please try to commenct line 1127 in hvm.c
> > hb_inkeyPoll();
> >to eliminate yet another possibly danger place and make test.
> I commented in hvm.c two active
> hb_inkeyPoll
1 - 100 of 147 matches
Mail list logo
