[qt-dev] Harbour hbqt* + qt461 for OS/2 advances

[David Macias]

test for "top-posting"

... coming from Ticket 133 "API_FPU_CW_Wrappers.h errors"


We have our firsts Harbour+os2gcc442+hbqt+qt461 applications running, but with
errors still
Many crashes with "Killed by SIGSEGV"

Tests were made with
Harbour 14019
os2Qt461 r598

Responses of Pritpal Bedi, our main hbqt* contribs developer suggested problems
in os2qt461, for example:
---------------------

It appears QDialog() class is also broken in OS2 builds.
It is also a very important class like QWidget and MUST behave
properly. I cannot figure out what is the issue. Please
experiment as
qMsgBox := QMessageBox():new( qMainWindow )

---------------------

and:

---------------------

so in this test both crashes are within MsgInfo() function trying to
clean/discard oMB object

And the destruction by GC is not what Qt likes.
It has its own "scopes" which interferes with Harbour's.
I am struggling with this phenomena most of the time
than development.

---------------------

and made many changes in general (for all OS):
---------------------

Yes. But the time you sent message I had changed the
hbIDE code a lot which denied me to reach a logical conclusion.
I will commit a big change within a day, so please make tests
after that.

---------------------

I tested with newer Harbour:
Harbour 14058
os2Qt461 r598

and Priptal responses to results are oriented again for likely problems in
os2qt461. Below are included Pritpal response with talks about three
specific cases

To be sure I made a fresh checkout and build of os2qt461 r642
Harbour 14058
os2Qt461 r642
and tests show exactly same errors

So as tests were made with newer Harbour+os2Qt461, is time to report to
"Netlabs" as Priptal requested me :-)

Suggestions for tests ?

David Macias

* $Id: ChangeLog 14058 2010-03-04 18:43:51Z druzus $
2010-03-04 19:43 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
so we have a newer Harbour and same os2Qt461
demoqt.prg
==========
MsgInfo( "Testing" )
result exactly same problem reported before
------------------------------------
demoqt.prg:127:MAIN(): HB_TR_ALWAYS
demoqt.prg:128:MAIN(): HB_TR_ALWAYS -----------------b-----------------
Exception c0000005 at address 0x1de369ca

Releasing the qObjects - in this case - QDialog -
is completely broken or is implemented in different way
in OS Qt. We need to ask netlabs.

MsgInfo( "Testing" )
result exactly same problem reported before
Called from QT_QWIDGET_RESIZE(0)
Called from QMAINWINDOW:RESIZE(0) in ../../../TQWidget.prg
------------------------------------
Called from QT_QWIDGET_RESIZE(0)
Called from QMAINWINDOW:RESIZE(0) in ../../../TQWidget.prg
Called from MAIN(141) in demoqt.prg

This is something strange and I do not have a clue.
:resize is the basic method of QWidget and is used extensively.
I have changed the order of QWidget:resize() in QWidget.qth
to make it compatible to Harbour calling convention
but QT_QWIDGET_RESIZE(0) call the underlying function
correctly. Again we need to ask netlabs.

hbide project
=============
-----------------------------
New failure
When run, show logo, build window with content and CRASH in 5 seconds
without human intervention. Tested many times and same behaviour
Something changed in hbqt*, hbide. With 13976 was running with some
failures, but do not crash in 5 seconds
Initial window size is different in both versions
-----------------------------
Called from HBIDE:CREATE(467) in hbide.prg
Called from MAIN(117) in hbide.prg

This is again the problem with destroying Qt object,
in this case qSplash ( qSplash := NIL ). So 1st and 3rd
suggest that OS Qt use other way of destroying the objects
than Qt Windows or Qt *nixes.

[Dmitry A. Kuminov]

Hi David,

Post by David Macias
... coming from Ticket 133 "API_FPU_CW_Wrappers.h errors"
We have our firsts Harbour+os2gcc442+hbqt+qt461 applications running, but with
errors still
Many crashes with "Killed by SIGSEGV"

I'm not familiar with Harbour, so the information you provide here doesn't give
me enough detail to say what can cause the crashes you have.

First of all, you need to build a debug version of Qt and a debug version of
Harbour and then try to reproduce your crashes using these debug builds -- I
don't know about Harbour, but Qt may print some useful messages to the console
that can give us a hint.

Next, if the above doesn't help, you will need to get an OS/2 debugger and run
the debug build from there. Using the debugger, we will be able to get the call
stack at a time of the crash and therefore locate the exact place in the source
code responsible for this.

Ask me if you need more details on how to get all this debug stuff.

Now, here are some general thoughts on the problems you mentioned.

Regarding broken classes. Of course, there may still be some OS/2-specific bugs
in our port of Qt, but all key classes generally "behave properly", at least in
a hundred Qt applications me and other people tried and tested -- you can see it
yourself if you install the demos and examples package and try to run
applications out there.

Regarding the order of size events, I must say that Qt for OS/2 indeed may (and
sometimes will) generate events in a different order compared to other
platforms: this often depends on the Presentation Manager and there is nothing
we can do about it. In general, application should not rely on the particular
event order because it is not guaranteed by the design of Qt.

Regarding the object destruction in Qt. I don't know if this is relevant or not,
but Qt uses a lot of global and local static objects (in terms of C++) that get
automatically constructed at program startup and destroyed at termination. In
C++, the order in which these objects are constructed and destructed, is not
guaranteed. I found one bug related to this issue in Qt itself (see r599 in the
SVN) but there may be more.

[David Macias]

Post by Dmitry A. Kuminov
I'm not familiar with Harbour, so the information you provide here doesn't give
me enough detail to say what can cause the crashes you have.

I know is not enough, and have many valuable missings
But if I include all info, messages result very large

Post by Dmitry A. Kuminov
First of all, you need to build a debug version of Qt and a debug version of
Harbour and then try to reproduce your crashes using these debug builds -- I
don't know about Harbour, but Qt may print some useful messages to the
console that can give us a hint.
Next, if the above doesn't help, you will need to get an OS/2 debugger
and
run the debug build from there. Using the debugger, we will be able to get
the call stack at a time of the crash and therefore locate the exact place
in the source code responsible for this.
Ask me if you need more details on how to get all this debug stuff.
Now, here are some general thoughts on the problems you mentioned.
Regarding broken classes. Of course, there may still be some OS/2-
specific bugs
in our port of Qt, but all key classes generally "behave properly", at least in
a hundred Qt applications me and other people tried and tested -- you can see it
yourself if you install the demos and examples package and try to run
applications out there.
Regarding the order of size events, I must say that Qt for OS/2 indeed may (and
sometimes will) generate events in a different order compared to other
platforms: this often depends on the Presentation Manager and there is
nothing we can do about it. In general, application should not rely on the
particular
event order because it is not guaranteed by the design of Qt.
Regarding the object destruction in Qt. I don't know if this is relevant or not,
but Qt uses a lot of global and local static objects (in terms of C++) that get
automatically constructed at program startup and destroyed at termination.
In C++, the order in which these objects are constructed and destructed,
is not
guaranteed. I found one bug related to this issue in Qt itself (see r599 in the
SVN) but there may be more.

Your "general thoughts" increase my worries about Harbour+os2qt461
As I see:
- Perhaps Harbour hbqt* wrappers are doing things wrongly
- Perhaps os2qt461 is doing things in different way than Win-Linux qt's
- Perhaps both above :-)

Until now we were working in a triangle:
- Me, re-building and testing
( I can build and test, have OS/2, but lack knowledge of Harbour and Qt internals)
- You, with guidelines and adjustments
( You have OS/2, know Qt internals but not Harbour )
- Pritpal Bedi, our Harbour qt* main developer, with guidelines and
adjustments
( Do not have OS/2, but know Harbour and Qt internals )

This working way cause long delays, misunderstandings, missings, ...
Maybe the big problems are there, but we can not see from our each corner

I suggest to you to build and test directly Harbour+hbqt*+os2qt461

- Harbour now build easily
- Harbour hb* now build easily in OS/2
- You have os2qt461 up to date
- And most important: you can review os2qt461 code and Harbour+hbqt* code
to check how is doing things

Here is a summary
( I am using Core2Duo E8400 3 GHz, so times may vary )

0) Your os2gcc442 environment as usual
Your os2qt46x up to date :-)

1) Harbour checkout:
https://harbour-project.svn.sourceforge.net/svnroot/harbour-project
/trunk/harbour <yourharbourdir>
- Resulting general directories structure will be as:
<yourharbourdir>\bin
<yourharbourdir>\lib
<yourharbourdir>\include
<yourharbourdir>\contrib\hbqt
<yourharbourdir>\contrib\hbide
<yourharbourdir>\contrib\hbxbp

2) Notes:
- You need make-3.81-r3 (release 3). Andreas Buening fixed release 2 to
work with Harbour
If you do not have or do not want release 3, it is included in SVN as
make-os2.exe
- INSTALL contain general info about platforms, compilers, settings, ...
You can skip reading INSTALL as I am explaining what you need :-)

3) To build Harbour
- Change to <yourharbourdir>
- set HB_COMPILER=gccomf
Mandatory of Harbour for OS/2
It is need to use OMF type libraries in Harbour
- os2-make.exe > make_gnu.log > 2>&1
or
make > make_gnu.log > 2>&1 if you have make r3 installed
- Build requires around 90 minutes with os2gcc442
( I do not why is so long. OpenWatcom 1.8 for OS/2 do in around 8 minutes )
- Resulting general directories structure will be as:
<yourharbourdir>\bin\os2\gccomf
<yourharbourdir>\lib\os2\gccomf


4) To build hbqt* libraries
- Do not forget "set HB_COMPILER=gccomf" if you changed session
- Change to <yourharbourdir>\contrib\hbqt

- Set environment for Harbour+hbqt
( Change e:\qt4 directory to yours )
Rem qt4 requirements
set C_INCLUDE_PATH=E:\qt4\mkspecs\default;%C_INCLUDE_PATH%
set CPLUS_INCLUDE_PATH=E:\qt4\mkspecs\default;%CPLUS_INCLUDE_PATH%
Rem hbqt* requirements
set HB_WITH_QT=E:\qt4\include
set HB_QT_MOC_BIN=E:\qt4\bin\moc.exe
- ..\os2-make.exe > make_hbqt.log > 2>&1
or
make > make_hbqt.log > 2>&1 if you have make r3 installed
- Build requires around 60 minutes with os2gcc442
( Question: will be OpenWatcom 1.8 for OS/2 support in os2qt46x ? )
- Resulting hbqt* libraries will be in:
<yourharbourdir>\lib\os2\gccomf
hbqt.lib
hbqtcore.lib
hbqtgui.lib
hbqtnetwork.lib

5) To test hbqt* samples
- Do not forget "set HB_COMPILER=gccomf" if you changed session
- Change to <yourharbourdir>\contrib\hbqt\tests

- Set environment for Qt46x runtime
You have it :-), but this is mine:

set LIBRARY_PATH=e:\OS2\DLL;e:\MPTN\DLL;%LIBRARY_PATH%
set PATH=E:\Qt4\bin;%PATH%
set BEGINLIBPATH=E:\Qt4\bin;%BEGINLIBPATH%

- Build demoqt.prg sample:
..\..\..\bin\os2\gccomf\hbmk2.exe demoqt.prg --trace
- hbmk2.exe is an Harbour tool to create Harbour executables in any platform
- run demoqt.exe > output.log 2>&1
It will fail with Resize case (check output.log):

Called from QT_QWIDGET_RESIZE(0)
Called from QMAINWINDOW:RESIZE(0) in ../../../TQWidget.prg

- To check object destruction case:
Add a line in demoqt.prg,
MsgInfo( "Testing" )
rebuild and run demoqt
It will fail with something as:

Called from MSGINFO(604) in demoqt.prg
Called from MAIN(131) in demoqt.prg

Below are my original description. You can follow to check secondary
object destruction case
( Current source lines may be different )

For hbide project
- Change to <yourharbourdir>\contrib\hbide

- Build hbide project:
..\..\bin\os2\gccomf\hbmk2.exe hbide.hbp --trace
- run hbide.exe > output.log 2>&1
It will fail about 5 seconds after main window display, with something as
(check output.log):

Called from HBIDE:CREATE(467) in hbide.prg
Called from MAIN(117) in hbide.prg

To check scaled case:
- Change to <yourharbourdir>\contrib\hbxbp\tests

- Build demoxbp.prg sample:
..\..\..\bin\os2\gccomf\hbmk2.exe demoxbp.prg --trace
- run demoxbp.exe > output.log 2>&1
It will fail with Scaled case (check output.log):

Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg
Called from XBPSTATUSBAR:SETPOINTER(0) in ../../../xbpwindow.prg


6) To check/change Harbour+hbqt* source code
Hbqt* are Harbour wrappers for qt*
Source code for our cases are in:
<yourharbourdir>\contrib\hbqt\ and deeper
<yourharbourdir>\contrib\hbide\ and deeper
<yourharbourdir>\contrib\hbxbp\ and deeper
and main Harbour source code are in:
<yourharbourdir>\src\ and deeper
You can change code as you need, rebuilding hbqt* libraries as
explained above, and recreating samples as explained above


As you can see, samples show errors in different cases using hbqt*+os2qt461

Sorry for long message, but I hope it will reduce many time/efforts/confutions
as you can check/handle cases directly

If you want, you can send direct requests/comments/guidelines to our
developers using Harbour development mailing list:
harbour /at/ harbour-project.org

and read messages in:
http://lists.harbour-project.org/pipermail/harbour/

My hope is to have an fully working Harbour+hbqt* before upcoming official
os2qt462 :-)
And if these Harbour cases help to improve os2qt462, much better

David Macias


===================
Using in demoqt.prg
[...]
HB_TRACE( HB_TR_ALWAYS, ( "-----------------b-----------------" ) )

//DAVID:
MsgInfo( "Testing" )

FOR i := 1 TO 1
oWnd := QMainWindow():new()
[...]

running demoqt.exe it show message window and crash after pressing OK
button with output:

-----------------------------------
demoqt.prg:127:MAIN(): HB_TR_ALWAYS
demoqt.prg:128:MAIN(): HB_TR_ALWAYS -----------------b-----------------

Exception c0000005 at address 0x1de369ca


Exception Code:C0000005
Exception Address:1DE369CA
EAX:00000001 EBX:02905FCC ECX:02905FD4 EDX:00000001
ESI:00000000 EDI:00000000 EBP:002FFB68
CS:EIP:005B:1DE369CA SS:ESP:0053:002FFB50
DS:0053 ES:0053 FS:150B GS:0000
Flags:00010246
Called from MSGINFO(604) in demoqt.prg
Called from MAIN(131) in demoqt.prg

Killed by SIGSEGV
pid=0x005f ppid=0x0041 tid=0x0001 slot=0x00ae pri=0x0200 mc=0x0001
E:\HARBOUR103\HARBOUR\CONTRIB\HBQT\TESTS\DEMOQT.EXE
LIBC063 0:000669ca
cs:eip=005b:1de369ca ss:esp=0053:002ffb50 ebp=002ffb68
ds=0053 es=0053 fs=150b gs=0000 efl=00010246
eax=00000001 ebx=02905fcc ecx=02905fd4 edx=00000001 edi=00000000
esi=00000000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
-----------------------------------

Current code is:

[596] STATIC FUNCTION MsgInfo( cMsg )
LOCAL oMB

oMB := QMessageBox():new()
oMB:setInformativeText( cMsg )
oMB:setWindowTitle( "Harbour-QT" )
oMB:exec()

[604] oMB := NIL
HB_GCALL( .T.)

[607] RETURN nil

so line 604 is:
oMB := NIL

Using:
//DAVID: oMB := NIL

crash again after OK button but now in line 607 which is:
RETURN nil

===================

[David Macias]

Dmitry A. Kuminov <dmik <at> hugaida.com> writes:

Posted again. Previous post does not appear on list after several time

Post by Dmitry A. Kuminov
I'm not familiar with Harbour, so the information you provide here doesn't give
me enough detail to say what can cause the crashes you have.

Sorry, I know is not enough, and have many valuable missings
But if I include all info, messages result very large

Post by Dmitry A. Kuminov
First of all, you need to build a debug version of Qt and a debug version of
Harbour and then try to reproduce your crashes using these debug builds -- I
don't know about Harbour, but Qt may print some useful messages to the
console that can give us a hint.
Next, if the above doesn't help, you will need to get an OS/2 debugger
and
run the debug build from there. Using the debugger, we will be able to get
the call stack at a time of the crash and therefore locate the exact place
in the source code responsible for this.
Ask me if you need more details on how to get all this debug stuff.
Now, here are some general thoughts on the problems you mentioned.
Regarding broken classes. Of course, there may still be some OS/2-
specific bugs
in our port of Qt, but all key classes generally "behave properly", at least in
a hundred Qt applications me and other people tried and tested -- you can see it
yourself if you install the demos and examples package and try to run
applications out there.
Regarding the order of size events, I must say that Qt for OS/2 indeed may (and
sometimes will) generate events in a different order compared to other
platforms: this often depends on the Presentation Manager and there is
nothing we can do about it. In general, application should not rely on the
particular
event order because it is not guaranteed by the design of Qt.
Regarding the object destruction in Qt. I don't know if this is relevant or not,
but Qt uses a lot of global and local static objects (in terms of C++) that get
automatically constructed at program startup and destroyed at termination.
In C++, the order in which these objects are constructed and destructed,
is not
guaranteed. I found one bug related to this issue in Qt itself (see r599 in the
SVN) but there may be more.

Your "general thoughts" increase my worries about Harbour+os2qt461
As I see:
- Perhaps Harbour hbqt* wrappers are doing things wrongly
- Perhaps os2qt461 is doing things in different way than Win-Linux qt's
- Perhaps both above :-)

Until now we were working in a triangle:
- Me, re-building and testing
( I can build and test, have OS/2, but lack knowledge of Harbour and Qt internals)
- You, with guidelines and adjustments
( You have OS/2, know Qt internals but not Harbour )
- Pritpal Bedi, our Harbour qt* main developer, with guidelines and
adjustments
( Do not have OS/2, but know Harbour and Qt internals )

This working way cause long delays, misunderstandings, missings, ...
Maybe the big problems are there, but we can not see from our each corner

I suggest to you to build and test directly Harbour+hbqt*+os2qt461

- Harbour now build easily
- Harbour hb* now build easily in OS/2
- You have os2qt461 up to date
- And most important: you can review os2qt461 code and Harbour+hbqt* code
to check how is doing things

Here is a summary
( I am using Core2Duo E8400 3 GHz, so times may vary )

0) Your os2gcc442 environment as usual
Your os2qt46x up to date :-)

1) Harbour checkout:
https://harbour-project.svn.sourceforge.net/svnroot/harbour-project
/trunk/harbour <yourharbourdir>
- Resulting general directories structure will be as:
<yourharbourdir>\bin
<yourharbourdir>\lib
<yourharbourdir>\include
<yourharbourdir>\contrib\hbqt
<yourharbourdir>\contrib\hbide
<yourharbourdir>\contrib\hbxbp

2) Notes:
- You need make-3.81-r3 (release 3). Andreas Buening fixed release 2 to
work with Harbour
If you do not have or do not want release 3, it is included in SVN as
make-os2.exe
- INSTALL contain general info about platforms, compilers, settings, ...
You can skip reading INSTALL as I am explaining what you need :-)

3) To build Harbour
- Change to <yourharbourdir>
- set HB_COMPILER=gccomf
Mandatory of Harbour for OS/2
It is need to use OMF type libraries in Harbour
- os2-make.exe > make_gnu.log > 2>&1
or
make > make_gnu.log > 2>&1 if you have make r3 installed
- Build requires around 90 minutes with os2gcc442
( I do not why is so long. OpenWatcom 1.8 for OS/2 do in around 8 minutes )
- Resulting general directories structure will be as:
<yourharbourdir>\bin\os2\gccomf
<yourharbourdir>\lib\os2\gccomf


4) To build hbqt* libraries
- Do not forget "set HB_COMPILER=gccomf" if you changed session
- Change to <yourharbourdir>\contrib\hbqt

- Set environment for Harbour+hbqt
( Change e:\qt4 directory to yours )
Rem qt4 requirements
set C_INCLUDE_PATH=E:\qt4\mkspecs\default;%C_INCLUDE_PATH%
set CPLUS_INCLUDE_PATH=E:\qt4\mkspecs\default;%CPLUS_INCLUDE_PATH%
Rem hbqt* requirements
set HB_WITH_QT=E:\qt4\include
set HB_QT_MOC_BIN=E:\qt4\bin\moc.exe
- ..\os2-make.exe > make_hbqt.log > 2>&1
or
make > make_hbqt.log > 2>&1 if you have make r3 installed
- Build requires around 60 minutes with os2gcc442
( Question: will be OpenWatcom 1.8 for OS/2 support in os2qt46x ? )
- Resulting hbqt* libraries will be in:
<yourharbourdir>\lib\os2\gccomf
hbqt.lib
hbqtcore.lib
hbqtgui.lib
hbqtnetwork.lib

5) To test hbqt* samples
- Do not forget "set HB_COMPILER=gccomf" if you changed session
- Change to <yourharbourdir>\contrib\hbqt\tests

- Set environment for Qt46x runtime
You have it :-), but this is mine:

set LIBRARY_PATH=e:\OS2\DLL;e:\MPTN\DLL;%LIBRARY_PATH%
set PATH=E:\Qt4\bin;%PATH%
set BEGINLIBPATH=E:\Qt4\bin;%BEGINLIBPATH%

- Build demoqt.prg sample:
..\..\..\bin\os2\gccomf\hbmk2.exe demoqt.prg --trace
- hbmk2.exe is an Harbour tool to create Harbour executables in any platform
- run demoqt.exe > output.log 2>&1
It will fail with Resize case (check output.log):

Called from QT_QWIDGET_RESIZE(0)
Called from QMAINWINDOW:RESIZE(0) in ../../../TQWidget.prg

- To check object destruction case:
Add a line in demoqt.prg,
MsgInfo( "Testing" )
rebuild and run demoqt
It will fail with something as:

Called from MSGINFO(604) in demoqt.prg
Called from MAIN(131) in demoqt.prg

Below are my original description. You can follow to check secondary
object destruction case
( Current source lines may be different )

For hbide project
- Change to <yourharbourdir>\contrib\hbide

- Build hbide project:
..\..\bin\os2\gccomf\hbmk2.exe hbide.hbp --trace
- run hbide.exe > output.log 2>&1
It will fail about 5 seconds after main window display, with something as
(check output.log):

Called from HBIDE:CREATE(467) in hbide.prg
Called from MAIN(117) in hbide.prg

To check scaled case:
- Change to <yourharbourdir>\contrib\hbxbp\tests

- Build demoxbp.prg sample:
..\..\..\bin\os2\gccomf\hbmk2.exe demoxbp.prg --trace
- run demoxbp.exe > output.log 2>&1
It will fail with Scaled case (check output.log):

Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg
Called from XBPSTATUSBAR:SETPOINTER(0) in ../../../xbpwindow.prg


6) To check/change Harbour+hbqt* source code
Hbqt* are Harbour wrappers for qt*
Source code for our cases are in:
<yourharbourdir>\contrib\hbqt\ and deeper
<yourharbourdir>\contrib\hbide\ and deeper
<yourharbourdir>\contrib\hbxbp\ and deeper
and main Harbour source code are in:
<yourharbourdir>\src\ and deeper
You can change code as you need, rebuilding hbqt* libraries as
explained above, and recreating samples as explained above


As you can see, samples show errors in different cases using hbqt*+os2qt461

Sorry for long message, but I hope it will reduce many time/efforts/confutions
as you can check/handle cases directly

If you want, you can send direct requests/comments/guidelines to our
developers using Harbour development mailing list:
harbour /at/ harbour-project.org

and read messages in:
http://lists.harbour-project.org/pipermail/harbour/

My hope is to have an fully working Harbour+hbqt* before upcoming official
os2qt462 :-)
And if these Harbour cases help to improve os2qt462, much better

David Macias


===================
Using in demoqt.prg
[...]
HB_TRACE( HB_TR_ALWAYS, ( "-----------------b-----------------" ) )

//DAVID:
MsgInfo( "Testing" )

FOR i := 1 TO 1
oWnd := QMainWindow():new()
[...]

running demoqt.exe it show message window and crash after pressing OK
button with output:

-----------------------------------
demoqt.prg:127:MAIN(): HB_TR_ALWAYS
demoqt.prg:128:MAIN(): HB_TR_ALWAYS -----------------b-----------------

Exception c0000005 at address 0x1de369ca


Exception Code:C0000005
Exception Address:1DE369CA
EAX:00000001 EBX:02905FCC ECX:02905FD4 EDX:00000001
ESI:00000000 EDI:00000000 EBP:002FFB68
CS:EIP:005B:1DE369CA SS:ESP:0053:002FFB50
DS:0053 ES:0053 FS:150B GS:0000
Flags:00010246
Called from MSGINFO(604) in demoqt.prg
Called from MAIN(131) in demoqt.prg

Killed by SIGSEGV
pid=0x005f ppid=0x0041 tid=0x0001 slot=0x00ae pri=0x0200 mc=0x0001
E:\HARBOUR103\HARBOUR\CONTRIB\HBQT\TESTS\DEMOQT.EXE
LIBC063 0:000669ca
cs:eip=005b:1de369ca ss:esp=0053:002ffb50 ebp=002ffb68
ds=0053 es=0053 fs=150b gs=0000 efl=00010246
eax=00000001 ebx=02905fcc ecx=02905fd4 edx=00000001 edi=00000000
esi=00000000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
-----------------------------------

Current code is:

[596] STATIC FUNCTION MsgInfo( cMsg )
LOCAL oMB

oMB := QMessageBox():new()
oMB:setInformativeText( cMsg )
oMB:setWindowTitle( "Harbour-QT" )
oMB:exec()

[604] oMB := NIL
HB_GCALL( .T.)

[607] RETURN nil

so line 604 is:
oMB := NIL

Using:
//DAVID: oMB := NIL

crash again after OK button but now in line 607 which is:
RETURN nil

===================

[David Macias]

Post by Dmitry A. Kuminov
I'm not familiar with Harbour, so the information you provide here doesn't give
me enough detail to say what can cause the crashes you have.

[...]

I tried to repeat tests with current Harbour and os2qt46x

With a fresh os2qt46x SVN checkout, r681, stop building with error:

-------------------------------------
g++ -c @tmp\obj\release-shared\CXXFLAGS.QtGui.Release.rsp
@tmp\obj\release-shared\DEFINES.QtGui.Release.rsp
@tmp\obj\release-shared\INCPATH.QtGui.Release.rsp -o
tmp\obj\release-shared\qrc_qmessagebox.obj
tmp\rcc\release-shared\qrc_qmessagebox.cpp
"..\..\mkspecs\os2-g++"\emxexpw.cmd -name QtGui4 -def ..\..\lib\QtGui4.def
-version "4.6.2.os2-g++" -desc "Qt4: C++ application development framework.
Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies)." -vendor
"DAVID4"
g++ -Zomf -Zstack 0x2000 -Zlinker "DISABLE 1121" -s -Zdll -Zhigh-mem -Zmap -o
..\..\lib\QtGui4.dll ..\..\lib\QtGui4.def
-Wl,@tmp\obj\release-shared\OBJECTS.QtGui.Release.rsp -Le:\qt4\lib -Le:\qt4\lib
-LE:\cups\lib -llibcups.a -lpthread.lib -lQtCore4
[...]
weakld: error: Unresolved symbol (UNDEF EXPORT) '_T.3032'.
weakld: info: The symbol is referenced by:
E:\qt4\src\gui\tmp\obj\release-shared\qmdisubwindow.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _T.3032 is an undefined reference
Error! E2044: exported symbol _T.3032 not found
make[2]: *** [..\..\lib\QtGui4.dll] Error 1
make[2]: Leaving directory `E:/qt4/src/gui'
make[1]: *** [release] Error 2
make[1]: Leaving directory `E:/qt4/src/gui'
make: *** [release-E__qt4_src_gui] Error 2
-------------------------------------

David Macias

[Silvan Scherrer]

yes it does,

if you search in the tickets you see that a new emxomf is needed.
see http://svn.netlabs.org/qt4/ticket/88
and http://svn.netlabs.org/libc/ticket/220

Post by David Macias

Post by Dmitry A. Kuminov
I'm not familiar with Harbour, so the information you provide here doesn't give
me enough detail to say what can cause the crashes you have.

[...]
I tried to repeat tests with current Harbour and os2qt46x
-------------------------------------
@tmp\obj\release-shared\DEFINES.QtGui.Release.rsp
@tmp\obj\release-shared\INCPATH.QtGui.Release.rsp -o
tmp\obj\release-shared\qrc_qmessagebox.obj
tmp\rcc\release-shared\qrc_qmessagebox.cpp
"..\..\mkspecs\os2-g++"\emxexpw.cmd -name QtGui4 -def ..\..\lib\QtGui4.def
-version "4.6.2.os2-g++" -desc "Qt4: C++ application development framework.
Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies)." -vendor
"DAVID4"
g++ -Zomf -Zstack 0x2000 -Zlinker "DISABLE 1121" -s -Zdll -Zhigh-mem -Zmap -o
..\..\lib\QtGui4.dll ..\..\lib\QtGui4.def
-LE:\cups\lib -llibcups.a -lpthread.lib -lQtCore4
[...]
weakld: error: Unresolved symbol (UNDEF EXPORT) '_T.3032'.
E:\qt4\src\gui\tmp\obj\release-shared\qmdisubwindow.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _T.3032 is an undefined reference
Error! E2044: exported symbol _T.3032 not found
make[2]: *** [..\..\lib\QtGui4.dll] Error 1
make[2]: Leaving directory `E:/qt4/src/gui'
make[1]: *** [release] Error 2
make[1]: Leaving directory `E:/qt4/src/gui'
make: *** [release-E__qt4_src_gui] Error 2
-------------------------------------
David Macias
---------------------------------------------------------------------

[David Macias]

Post by Silvan Scherrer
yes it does,
if you search in the tickets you see that a new emxomf is needed.
see http://svn.netlabs.org/qt4/ticket/88
and http://svn.netlabs.org/libc/ticket/220

Thanks Silvan
I checked both tickets and download
emxomf-for-qt-2010-03-12.zip
which contain
119519 0 0 12-03-10 02:30 emxomf.exe

In my harddisk exist:

Directory of E:\usr\bin
11/06/07 10:52p 126,976 0 a--- emxomf.exe
Directory of E:\usr\local432\bin
30/09/08 7:26p 91,409 0 a--- emxomf.exe
Directory of E:\usr\local433\bin
30/09/08 7:26p 91,409 0 a--- emxomf.exe
Directory of E:\usr\local434\bin
19/04/09 5:16a 208,544 0 a--- emxomf.exe
Directory of E:\usr\local44\bin
19/04/09 5:16a 208,544 0 a--- emxomf.exe
Directory of E:\usr\local442\bin
19/04/09 5:16a 208,544 0 a--- emxomf.exe

I do not want to make an mistake in replacement with unpredictable results

Which emxomf.exe must I replace ?
E:\usr\bin (gcc335)
or
E:\usr\local442\bin (gcc442)

I guess gcc442, but file size is near of gcc335

David Macias

[Dmitry A. Kuminov]

Post by David Macias
Which emxomf.exe must I replace ?
E:\usr\bin (gcc335)
or
E:\usr\local442\bin (gcc442)

Replace all.