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 that
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 fail
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 anything
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 disabled debug
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
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-platform build
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 any
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 mode waiting
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.
Confused state ON In your prev mail you told that full removal
of -s also doesn't help
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
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
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
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 1204,
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
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 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:
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
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 limit:
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 whole
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, set
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
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 is
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
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 bigger
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
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
:
--
[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
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
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 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 difference when
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
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
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,
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, what
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 when
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
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
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
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
Przemyslaw,
GCC has this code inside libos2 which is linked with every program:
---8
/* kbd4.c */
#define INCL_KBD
#include os2.h
USHORT _THUNK_FUNCTION (Kbd16CharIn) ();
USHORT KbdCharIn (PKBDKEYINFO pkbci, USHORT fWait, HKBD hkbd)
{
return ((USHORT)
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
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
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 ?
They
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 OS2
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 the
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 os2.h
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
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
---
SYS1808:
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
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 os2.h
USHORT _THUNK_FUNCTION (Kbd16CharIn) ();
USHORT KbdCharIn (PKBDKEYINFO pkbci, USHORT
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
us
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 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
[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 find
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:
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'll fix
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 MT
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:
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
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
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
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
../../hboutdbg.c(166):
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] Error 2
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.
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:33a21,046
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
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
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 happens.
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, it
Przemek:
I'm build systematically MS-Windows OpenWatcom 1.2 binaries
in Linux using WINE and MT mode is working without any problems.
The Windows version is working correctly. At least for me using OW1.2
with Wine. Later I'll install new OW1.7 and check but I do not expect
problems. It's
I can. But now I have 7days holiday.
and you are now in disconnecting phase :-)
Thanks Marek
I am using OpenWatcom 1.7a
David Macias
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
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();
and error has gone
Using -bm flag and hbvmmt
-
1.
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
SYS1808:
The
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.
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.
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:
announce
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 hope to
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.
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 your
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 virtual
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
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 =
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 and
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 )
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();
and
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(stdout); }
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
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 are
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 line:
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_inkeyPoll()
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 necessary
Przemek:
I'm attaching modified thread.c file.
Url :
http://lists.harbour-project.org/pipermail/harbour/attachments/20081107/4c83ebf2/thread.c-0001.gz
Checked with WarpZip and Linux-Ark and both confirm: thread.c-0001.gz is
empty
Can you send me thread.c in zip to my e-mail ?
David Macias
Przemek:
:-) So this is working correctly.
Now we will have to check where it fails.
I'm attaching modified thread.c file.
Please put it in harbour/source/vm/ directory and rebuild Harbour.
Then try to compile and execute this time .prg code:
proc main()
hb_threadJoin( hb_threadStart(
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
Using -bm flag and hbvmmt
---
1. HB_THREADSTART
1. hb_threadStartVM
3. HB_THREADSTART
2. hb_threadStartVM
1. hb_vmThreadInit()
2. hb_vmThreadInit()
3. hb_vmThreadInit()
4. hb_vmThreadInit()
SYS1808:
The
Przemek:
Take note: I changed C code myself :-)
I added 4a, 4b, 4c, 4d:
printf( 4. hb_vmThreadInit()\n\r );fflush(stdout);
if( pState-pszDefRDD )
printf( 4a. hb_vmThreadInit()\n\r );fflush(stdout);
hb_stackRDD()-szDefaultRDD = pState-pszDefRDD;
Przemek:
Somebody tested Harbour / OpenWatcom 1.7 in Windows ?
Perhaps have the same problem of OS/2 and if so it will be very easy to
test in your environment
David Macias
___
Harbour mailing list
Harbour@harbour-project.org
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
Somebody tested Harbour / OpenWatcom 1.7 in Windows ?
I'm build systematically MS-Windows OpenWatcom 1.2 binaries
in Linux using WINE and MT mode is working without any problems.
Perhaps have the same problem of OS/2 and if so
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
Take note: I changed C code myself :-)
Thanks :-)
[...]
14. hb_vmDo()
15. hb_vmDo()
16. hb_vmDo() -- note 18 ?
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 0001.
So it will
On Fri, 07 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
Using -bm flag and hbvmmt
---
1. hb_stackInit()
2. hb_stackInit()
3. hb_stackInit()
4. hb_stackInit(00130034)
5. hb_stackInit()
1. HB_THREADSTART
1. hb_threadStartVM
3. HB_THREADSTART
2. hb_threadStartVM
Przemek:
Thank you. Looks that is fails not 1-st memory allocation or TLS
access.
So now next step. Please replace hb_stackInit() function
in source/vm/estack.c with this code:
void hb_stackInit( void )
{
HB_TRACE(HB_TR_DEBUG, (hb_stackInit()));
printf(1. hb_stackInit()\n);fflush(stdout);
1 - 100 of 131 matches
Mail list logo
