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

[David Macias]

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

Replace all.

Thanks,

After many tries due lack of time, finally os2qt462 r701 build entirely

I included below my report to Harbour mailing list, of tests for our 4 specific
error cases

One case has been solved:
Case: QT_QWIDGET_RESIZE(0)
PMMERGE 3:0007f6f8
and I guess is due to r698 fix

Questions:
- This case is solved due to r698 ?
- If so, fix was applied after local tests with Harbour, or due some other case
in os2qt development/tests ?

Harbour hbqt* have many changes for all OS and of course os2qt* have many
changes in code too, so consequential changes/fixes are expected, even if they
are not checked directly

I still consider your direct tests with Harbour-os2qt462 as best way to deal
with these cases, but I understand your impossibility to make this kind of tests

So I added my report with hope to get fixes due "normal" hbqt*/os2qt*
development, as consequential changes/fixes in both sides and not specific
direct checks

David Macias


Pritpal:

Tests with Harbour fresh checkout:
* $Id: ChangeLog 14189 2010-03-19 13:11:59Z vszakats $
2010-03-19 14:04 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)


os2qt development has moved to Qt462
Current tests with os2qt462 r701

so we have a newer Harbour and newer os2Qt462

With our 4 specific error cases
- one has been fixed (a)
- one changed behaviour (c)
- two remain with same behaviour (b, d)


a) demoqt.prg
Case: QT_QWIDGET_RESIZE(0)
PMMERGE 3:0007f6f8
Fixed
For first time in history I see demoqt.exe running on OS/2


b) demoqt.prg, MsgInfo( "Testing" ) added
Case: Object destruction
LIBC063 0:000669ca
Remain
Question: Is this a common problem in hbqt in rest of platforms, or
exist only in OS/2 ?

This is (1,2) 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:0290FC8C ECX:0290FC94 EDX:00000001
ESI:00000000 EDI:00000000 EBP:0030FB68
CS:EIP:005B:1DE369CA SS:ESP:0053:0030FB50
DS:0053 ES:0053 FS:150B GS:0000
Flags:00010246
Called from MSGINFO(605) in demoqt.prg
Called from MAIN(131) in demoqt.prg

Killed by SIGSEGV
pid=0x45d1 ppid=0x459d tid=0x0001 slot=0x00a4 pri=0x0200 mc=0x0001
E:\HARBOUR103C\HARBOUR\CONTRIB\HBQT\TESTS\DEMOQT.EXE
LIBC063 0:000669ca
cs:eip=005b:1de369ca ss:esp=0053:0030fb50 ebp=0030fb68
ds=0053 es=0053 fs=150b gs=0000 efl=00010246
eax=00000001 ebx=0290fc8c ecx=0290fc94 edx=00000001 edi=00000000
esi=00000000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

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


c) hbide project
Case: hbide crash at startup
LIBC063 0:000669ca
Changed behaviour

My description was, for previous behaviour:
-----------------------------
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
-----------------------------


In current behaviour, show logo and never build window, then crash

This is (1,2) output:

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

idemisc.prg:925:HBIDE_DBG(): HB_TR_ALWAYS NIL
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockProjectTree", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockEditorTabs", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockFuncList", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockSkltnsTree", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockHelp", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockSkeleton", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockFindInFiles", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockThemes", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockProperties", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockEnvironments", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockCompileResults", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockLinkResults", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockOutputResults", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockDocViewer", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockDocWriter", which already has a layout
QWidget::setLayout: Attempting to set QLayout "" on QDockWidget
"dockFunctions", which already has a layout

Exception c0000005 at address 0x1de369ca

Exception Code:C0000005
Exception Address:1DE369CA
EAX:00000001 EBX:02C00F6C ECX:02C00F74 EDX:00000001
ESI:00000000 EDI:02C00F9C EBP:005CFCE8
CS:EIP:005B:1DE369CA SS:ESP:0053:005CFCD0
DS:0053 ES:0053 FS:150B GS:0000
Flags:00010246
Called from HBIDE:CREATE(487) in hbide.prg
Called from MAIN(117) in hbide.prg

Killed by SIGSEGV
pid=0x45f7 ppid=0x459d tid=0x0001 slot=0x00a2 pri=0x0200 mc=0x0001
E:\HARBOUR103C\HARBOUR\CONTRIB\HBIDE\HBIDE.EXE
LIBC063 0:000669ca
cs:eip=005b:1de369ca ss:esp=0053:005cfcd0 ebp=005cfce8
ds=0053 es=0053 fs=150b gs=0000 efl=00010246
eax=00000001 ebx=02c00f6c ecx=02c00f74 edx=00000001 edi=02c00f9c
esi=00000000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
------------------------------------


d) demoxbp.prg
Case: QPIXMAP:SCALED(0)
LIBC063 0:000669ca
Remain

This is (1,2) output:

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

Exception c0000005 at address 0x1de369ca

Exception Code:C0000005
Exception Address:1DE369CA
EAX:00000001 EBX:02A9D15C ECX:02A9D164 EDX:00000001
ESI:00000000 EDI:02A9D124 EBP:0039F728
CS:EIP:005B:1DE369CA SS:ESP:0053:0039F710
DS:0053 ES:0053 FS:150B GS:0000
Flags:00010246
Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg
Called from XBPSTATUSBAR:SETPOINTER(0) in ../../../xbpwindow.prg
Called from BUILD_STATUSBAR(531) in demoxbp.prg
Called from BUILDADIALOG(168) in demoxbp.prg
Called from _BUILDADIALOG(107) in demoxbp.prg
Called from MAIN(98) in demoxbp.prg

Killed by SIGSEGV
pid=0x4612 ppid=0x459d tid=0x0001 slot=0x0096 pri=0x0200 mc=0x0001
E:\HARBOUR103C\HARBOUR\CONTRIB\HBXBP\TESTS\DEMOXBP.EXE
LIBC063 0:000669ca
cs:eip=005b:1de369ca ss:esp=0053:0039f710 ebp=0039f728
ds=0053 es=0053 fs=150b gs=0000 efl=00010246
eax=00000001 ebx=02a9d15c ecx=02a9d164 edx=00000001 edi=02a9d124
esi=00000000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
------------------------------------


Previously I reported cases to NetLabs/osqt development

[...]

[Dmitry A. Kuminov]

Post by David Macias
Case: QT_QWIDGET_RESIZE(0)
PMMERGE 3:0007f6f8
and I guess is due to r698 fix
- This case is solved due to r698 ?

Yes. I had it crashing at exactly the same address. Good to hear that it fixed a
problem for you as well.

Post by David Macias
- If so, fix was applied after local tests with Harbour, or due some other case
in os2qt development/tests ?

No. I found it doing my own tests.

Post by David Macias
b) demoqt.prg, MsgInfo( "Testing" ) added
Case: Object destruction
LIBC063 0:000669ca
Remain
Question: Is this a common problem in hbqt in rest of platforms, or
exist only in OS/2 ?

You may wish to try to get a process dump and send it over to me. To do this,
issue a command 'procdump on /L:X:\' where X: is a drive with enough space and
then start an application that crashes. It will create a file called
X:\PDUMP.000 which you should zip and send to me. I *may* have a look at it when
I have free time.

Post by David Macias
c) hbide project
Case: hbide crash at startup
LIBC063 0:000669ca
Changed behaviour

Looks as it the same as b). The same need for the process dump.

Post by David Macias
d) demoxbp.prg
Case: QPIXMAP:SCALED(0)
LIBC063 0:000669ca
Remain

Same as above as well.

[David Macias]

Post by Dmitry A. Kuminov
Yes. I had it crashing at exactly the same address. Good to hear that it
fixed a problem for you as well.

[...]

Post by Dmitry A. Kuminov
You may wish to try to get a process dump and send it over to me. To do this,
issue a command 'procdump on /L:X:\' where X: is a drive with enough space and
then start an application that crashes. It will create a file called
X:\PDUMP.000 which you should zip and send to me. I *may* have a look at it
when I have free time.

hbqtpdump.zip, 1.2 Mbytes

You can download from
http://suphost.no-ip.biz/hbqtpdump.zip

PDUMP.000: b) demoqt.prg, MsgInfo( "Testing" ) added
PDUMP.001: c) hbide project
PDUMP.002: d) demoxbp.prg, Case: QPIXMAP:SCALED(0)

Thanks for your interest and your *free* time :-)

David Macias

[David Macias]

to avoid top-posting warning

Dmitry:

Below are response of Pritpal

Case "c) hbide crash at startup" was solved with this commit (r14198):

2010-03-20 07:53 UTC-0800 Pritpal Bedi (***@vouchcac.com)
* contrib/hbide/hbide.prg
! Postponed destruction of QSplashScreen(),
always producing GPF on OS2, to take care of by Qt itself.

change was comment in this line:
//qSplash := NIL

so it now belong to "object destruction" cases


For case "d) QPIXMAP:SCALED(0)", Pritpal say:

"This is bug in OS Qt in QPixmap() class.
Tell Dmitry specifically pointing to this issue only."

As I understand, you should review only d) case and forget "object
destruction cases (b, c)" until Pritpal clarify "behavior of GC and
Qt's destruction mechanism"

Thanks for your help

David Macias

* $Id: ChangeLog 14189 2010-03-19 13:11:59Z vszakats $
2010-03-19 14:04 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
os2qt development has moved to Qt462
Current tests with os2qt462 r701
so we have a newer Harbour and newer os2Qt462

Thanks for your constant efforts, someday we will reach a solution, for
sure.

With our 4 specific error cases
- one has been fixed (a)
- one changed behaviour (c)
- two remain with same behaviour (b, d)
a) demoqt.prg
Case: QT_QWIDGET_RESIZE(0)
PMMERGE 3:0007f6f8
Fixed
For first time in history I see demoqt.exe running on OS/2

All the good.

b) demoqt.prg, MsgInfo( "Testing" ) added
Case: Object destruction
LIBC063 0:000669ca
Remain
Question: Is this a common problem in hbqt in rest of platforms, or
exist only in OS/2 ?

This is the behavior of GC and Qt's destruction mechanism, see below.

c) hbide project
Case: hbide crash at startup
LIBC063 0:000669ca
Changed behaviour
In current behaviour, show logo and never build window, then crash

Probably fixed in r14198, please test.
It is again a "destruction of object" issue.

d) demoxbp.prg
Case: QPIXMAP:SCALED(0)
LIBC063 0:000669ca
Remain
Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg

This is bug in OS Qt in QPixmap() class.
Tell Dmitry specifically pointing to this issue only.

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.

The above reply portrays the snapshot of our GC way of destruction
and how Qt handles them, all timing problem. This is one factor I always
struggle about. If we do away with GC pointers, everything goes OK
but then application keeps on eating memory unless we reuse
the objects, that was the case with first few months of development.

I am writing an artical on Harbour-Qt implementation focusing
on object creation and destruction mechanism. Once that is in place,
we can request netlabs to look into it deeply and suggest us
what should be our strategy.

Thank you for constant efforts.

[Silvan Scherrer]

David,

thanks for the report. But as i told you more than one time. We can't
and we will not look ate the remaining cases if we do not recieve
sponsorship units from the harbor-qt project. we just have not the
ressources to do so. even it would not take more than a couple of hours
for Dmitry to look at it and try to compile. Every hour costs money,
which then is not available to produce a release at all.

regards
Silvan

Post by David Macias

to avoid top-posting warning

Below are response of Pritpal
* contrib/hbide/hbide.prg
! Postponed destruction of QSplashScreen(),
always producing GPF on OS2, to take care of by Qt itself.
//qSplash := NIL
so it now belong to "object destruction" cases
"This is bug in OS Qt in QPixmap() class.
Tell Dmitry specifically pointing to this issue only."
As I understand, you should review only d) case and forget "object
destruction cases (b, c)" until Pritpal clarify "behavior of GC and
Qt's destruction mechanism"
Thanks for your help
David Macias

* $Id: ChangeLog 14189 2010-03-19 13:11:59Z vszakats $
2010-03-19 14:04 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
os2qt development has moved to Qt462
Current tests with os2qt462 r701
so we have a newer Harbour and newer os2Qt462

Thanks for your constant efforts, someday we will reach a solution, for
sure.

With our 4 specific error cases
- one has been fixed (a)
- one changed behaviour (c)
- two remain with same behaviour (b, d)
a) demoqt.prg
Case: QT_QWIDGET_RESIZE(0)
PMMERGE 3:0007f6f8
Fixed
For first time in history I see demoqt.exe running on OS/2

All the good.

b) demoqt.prg, MsgInfo( "Testing" ) added
Case: Object destruction
LIBC063 0:000669ca
Remain
Question: Is this a common problem in hbqt in rest of platforms, or
exist only in OS/2 ?

This is the behavior of GC and Qt's destruction mechanism, see below.

c) hbide project
Case: hbide crash at startup
LIBC063 0:000669ca
Changed behaviour
In current behaviour, show logo and never build window, then crash

Probably fixed in r14198, please test.
It is again a "destruction of object" issue.

d) demoxbp.prg
Case: QPIXMAP:SCALED(0)
LIBC063 0:000669ca
Remain
Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg

This is bug in OS Qt in QPixmap() class.
Tell Dmitry specifically pointing to this issue only.

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.

The above reply portrays the snapshot of our GC way of destruction
and how Qt handles them, all timing problem. This is one factor I always
struggle about. If we do away with GC pointers, everything goes OK
but then application keeps on eating memory unless we reuse
the objects, that was the case with first few months of development.
I am writing an artical on Harbour-Qt implementation focusing
on object creation and destruction mechanism. Once that is in place,
we can request netlabs to look into it deeply and suggest us
what should be our strategy.
Thank you for constant efforts.
---------------------------------------------------------------------