Qt (mingw) + Qtcontribs building across various versions

[Zoran Sibinovic]

Hello everyone,

I started this topic to unite and exchange experiences in building various Qtcontribs+Qt (mingw) versions.

More over a decade ago I started the
Unrecoverable error 6005: Exception error: Exception Code:C0000005 ACCESS_VIOLATION
topic since is was my worst nightmere till two weeks ago.

Thanks to Pritpal, Alex, Francesco, other several our members an various AI suggestions I succeeded t0 overcome the Qt 5.5.x version with a working composite.exe, with a newer and stepped forward.

I have to note that I use only hbqtwidgets since it suits all my needs and the below examples focus only on it but I think taht the other modules can be compiled as well.

In the following, I will share my experience in building Qtcontribs (r.484, r485) and QT 5.5.1, 5.9.9, 5.12.12 and 5.15.2 versions becouse they are LTS and the most stable through the others. My harbour folder is c:\hb and Qt-s is c:\Qt.

Qt 5.5.1(mingw492_32) and Qtcontribs r484

Qtcontribs r484 is the latest revision that all hbqtwidgets test .prg work and with and compile without errors or watrnings.

Qt 5.5.1(mingw492_32) and Qtcontribs r485

Not built ...

Generating C source output to 'C:\hb\addons\hbqt\.hbmk\win\mingw\hbqtgui\hbqt_errorsys.c'... Done.
hbmk2: Compiling...
hbmk2: Compiling C++...
C:/hb/addons/hbqt/.hbmk/win/mingw/hbqtgui/QAction.cpp: In function 'void HB_FUN_QACTION()':
C:/hb/addons/hbqt/.hbmk/win/mingw/hbqtgui/QAction.cpp:142:63: error: no matching function for call to 'QAction::QAction(const char*)'
pObj = new QAction( hb_parstr_utf8( 1, &pText01, NULL ) );
^
C:/hb/addons/hbqt/.hbmk/win/mingw/hbqtgui/QAction.cpp:142:63: note: candidates are:
In file included from C:/hb/addons/hbqt/qtcore/hbqt.h:76:0,
from C:/hb/addons/hbqt/.hbmk/win/mingw/hbqtgui/QAction.cpp:7:
C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtWidgets/qaction.h:192:20: note: QAction::QAction(const QAction&)
Q_DISABLE_COPY(QAction)
^
C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtCore/qglobal.h:1042:5: note: in definition of macro 'Q_DISABLE_COPY'
Class(const Class &) Q_DECL_EQ_DELETE;\
^
C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtWidgets/qaction.h:192:20: note: no known conversion for argument 1 from 'const char*' to 'const QAction&'
Q_DISABLE_COPY(QAction)
^
C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtCore/qglobal.h:1042:5: note: in definition of macro 'Q_DISABLE_COPY'
Class(const Class &) Q_DECL_EQ_DELETE;\
^
In file included from C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtWidgets/QAction:1:0,
from C:/hb/addons/hbqt/.hbmk/win/mingw/hbqtgui/QAction.cpp:66:
C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtWidgets/qaction.h:174:5: note: QAction::QAction(QActionPrivate&, QObject*)
QAction(QActionPrivate &dd, QObject *parent);
^
C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtWidgets/qaction.h:174:5: note: candidate expects 2 arguments, 1 provided
C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtWidgets/qaction.h:89:5: note: QAction::QAction(const QIcon&, const QString&, QObject*)

QAction(const QIcon &icon, const QString &text, QObject* parent);
^
C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtWidgets/qaction.h:89:5: note: candidate expects 3 arguments, 1 provided
C:/Qt/Qt5.5.1/5.5/mingw492_32/include/QtWidgets/qaction.h:88:5: note: QAction::QAction(const QString&, QObject*)
QAction(const QString &text, QObject* parent);
...
Not solved yet

Qt 5.9.9 (mingw530_32) and Qtcontribs r485
Compiles without error/warnings but composite.exe crashes during its usage.
Problem solved by Alex modification of hbqt_bind.cpp, composite.exe works but not validator.exe

AI told me that is a kind of a destroy competition between Qt (become more aggresive and strict with the introduction of c++), harbour and qtcontribs. Who reach the girl first than it will be his. In our case it is the destroy timing without control if some object is already destroyed. Qt destroys it and release the memory and then ... here it comes harbor ot qtcontribs to do the same thing. There are a lot of combinations but noone with an: IF the object is defined -> destroy it ELSE just proceed ENDIF line.

Qt 5.12.12 (mingw730_32) and Qtcontribs r485
Composite works with Alex modifications of hbqt_bind.cpp, hbmk2_qt.hb and hbqt_misc.prg.

(In hbqt_misc.prg must omit #ifdef
/--------------------------------------------------------------------//
// Hacks to Cover Qt 4.x
//--------------------------------------------------------------------//
// #ifdef __HB_QT_MAJOR_VER_4__
FUNCTION QApplication_translate( p1, p2 )
HB_SYMBOL_UNUSED( p1 )
RETURN p2
// #endif

(dont know why this come now and not in the previous versions because during the compile ofcomposite, it shows QApplication_translate() as unknown function. Also because the unaltered code works with 5.5, 5.8 and 5.9.9 ))

In the usage of the environment variablese there are also differences  

1. with SETX /M HB_USER_CFLAGS "-std=gnu++11"
it shows in the log a lot of this warnings:
...
Lines 1302, Functions/Procedures 16
Generating C source output to 'C:\hb\addons\hbqt\.hbmk\win\mingw\hbqtcore\hbqt_misc.c'... Done.
hbmk2: Compiling...
cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C
cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C
cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C
hbmk2: Compiling C++...
C:/hb/addons/hbqt/qtcore/hbqt_bind.cpp: In function 'void hbqt_bind_init(void*)':
C:/hb/addons/hbqt/qtcore/hbqt_bind.cpp:116:69: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
#define hbqt_bindGetData() ( ( ( PHB_BIND_DATA ) &s_bindData )->s_hbqt_binds )
^
C:/hb/addons/hbqt/qtcore/hbqt_bind.cpp:116:69: note: in definition of macro 'hbqt_bindGetData'
#define hbqt_bindGetData() ( ( ( PHB_BIND_DATA ) &s_bindData )->s_hbqt_binds )
^~
C:/hb/addons/hbqt/qtcore/hbqt_bind.cpp: In function 'QList<void*> hbqt_bindGetObjectListByThread(int)':
C:/hb/addons/hbqt/qtcore/hbqt_bind.cpp:116:69: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
#define hbqt_bindGetData() ( ( ( PHB_BIND_DATA ) &s_bindData )->s_hbqt_binds )
...

It finishes but ... not sure about other implications

2. with SETX /M HB_USER_CFLAGS "-std=gnu++11 -fno-strict-aliasing -Wno-strict-aliasing"

no errors or warnings is shown also,


3. with SETX /M HB_USER_CFLAGS "-std=gnu++11"

... shows all the way warnings in 116th line in hbqt_bind.cpp about 

#define hbqt_bindGetData() ( ( ( PHB_BIND_DATA ) &s_bindData )->s_hbqt_binds )

.. by replacing it with
#define hbqt_bindGetData() ( s_bindData->s_hbqt_binds )

no warnings anymore. Validator.exe still not works.

Qt 5.15.2 (mingw810_32) and Qtcontribs r485
Composite works with Alex modifications of hbqt_bind.cpp, hbmk2_qt.hb and hbqt_misc.prg. and
SETX /M HB_USER_CFLAGS "-std=gnu++11 -fno-strict-aliasing -Wno-strict-aliasing"

even than it shows in the log a lot of this warnings:
...
Lines 1302, Functions/Procedures 16
Generating C source output to 'C:\hb\addons\hbqt\.hbmk\win\mingw\hbqtcore\hbqt_misc.c'... Done.
hbmk2: Compiling...
cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C
cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C
cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C
hbmk2: Compiling C++...
C:/hb/addons/hbqt/.hbmk/win/mingw/hbqtcore/HBQString.cpp: In function 'void HB_FUN_SPLIT()':
C:/hb/addons/hbqt/.hbmk/win/mingw/hbqtcore/HBQString.cpp:1991:365: warning: 'QStringList QString::split(const QString&, QString::SplitBehavior, Qt::CaseSensitivity) const' is deprecated: Use Qt::SplitBehavior variant instead [-Wdeprecated-declarations]
hb_itemReturnRelease( hbqt_bindGetHbObject( NULL, new QStringList( p->split( ( QString ) hb_parstr_utf8( 1, &pText01, NULL ), ( HB_ISNUM( 2 ) ? ( HBQString::SplitBehavior ) hb_parni( 2 ) : ( HBQString::SplitBehavior ) HBQString::KeepEmptyParts ), ( HB_ISNUM( 3 ) ? ( Qt::CaseSensitivity ) hb_parni( 3 ) : ( Qt::CaseSensitivity ) Qt::CaseSensitive ) ) ), "HB_QSTRINGLIST", hbqt_del_QStringList, HBQT_BIT_NONE | HBQT_BIT_OWNER ) );
^
In file included from C:/Qt/Qt5.15.2/5.15.2/mingw81_32/include/QtCore/qobject.h:47,
from C:/Qt/Qt5.15.2/5.15.2/mingw81_32/include/QtCore/QObject:1,
from C:/hb/addons/hbqt/qtcore/hbqt.h:78,
from C:/hb/addons/hbqt/.hbmk/win/mingw/hbqtcore/HBQString.cpp:7:
C:/Qt/Qt5.15.2/5.15.2/mingw81_32/include/QtCore/qstring.h:609:17: note: declared here
QStringList split(const QString &sep, SplitBehavior behavior,
...
Validator still not works.

In the attachment are the modificated files that i use.

Please replace the extensions .zoran with .bat and they runs as administrator.
The modifications in hbqt_bind.cpp, hbmk2_qt.hb and hbqt_misc.prg are from Alex.
The other, .bat-s are for mine environment and build.

Since there are lot of gymnastic from the 5.12 version, at this moment, I will stay at Qt 5.9.9 as the most covered by its mingw and r.485 qtcontribs.

Waiting for the discussion.
Thanks
Zoran

[Francesco Perillo]

Thank you Zoran for this recap.

A) I tried a Qt5.5.1 compiled composite.exe on a windows 11 and it worked. All my other workstations were W10 so I excluded changes in the OS

B) in hbqt\hbmk_common.hbm add the line

-cpp=iso11

and all the warnings will disappear.

Pritpal committed this patch 

diff --git a/hbqt/hbmk2_qt.hb b/hbqt/hbmk2_qt.hb
index a897aa4..37e0708 100644
--- a/hbqt/hbmk2_qt.hb
+++ b/hbqt/hbmk2_qt.hb
@@ -73,7 +73,8 @@ FUNCTION hbmk_plugin_qt( hbmk )
       ENDIF
       IF "5.7" $ cVer .AND. hbmk[ "cCOMP" ] == "mingw"
          hb_SetEnv( "HB_QT_MINOR_VER", "7" )
-         hb_SetEnv( "HB_USER_CFLAGS", hb_GetEnv( "HB_USER_CFLAGS" ) + " -std=c++11" )
+      ELSEIF "5.8" $ cVer .AND. hbmk[ "cCOMP" ] == "mingw"
+         hb_SetEnv( "HB_QT_MINOR_VER", "8" )
       ENDIF
 
       IF ! Empty( GetEnv( "QTCONTRIBS_REBUILD" ) )

This patch also sets HB_QT_MINOR_VER to 8, something you were talking about , if I remember correctly

C) I get the crash when I open the form, not when I close it, not when I exit the program, only when I open. It may be the 3rd or 25th time I open the form.

C1) I compiled hbQt with HB_TRACE enabled and it seems the problem is inside Qt code... well, the crash is in the Qt code but probably we give some wrong informations.

C2) I hand-traced all the object deletetion and found no problems; I should add some more HB_TRACE

C3) the last lines in the trace logs are:

composite.prg:143:CUSTINFO(): HB_TR_DEBUG A009
hbqt/qtcore/hbqt_pointer.cpp:92: HB_TR_DEBUG hbqt_par_ptr( 0 )
hbqt/qtcore/hbqt_bind.cpp:854: HB_TR_DEBUG hbqt_bindGetQtObject(pObject=0657473C) enter
hbqt/qtcore/hbqt_bind.cpp:867: HB_TR_DEBUG hbqt_bindGetQtObject(qtObject=07F013E8) exit

Please note that A009 is the line just before oDlg:exec(), so the crash is inside the exec() loop.

C4) I think that every time in hbqt_bind() there is this line:

qObject->disconnect();

we should retrieve the Harbour object and call method disconnect(), that translates to calling

METHOD HbQtObjectHandler:disconnect( cnEvent )

and the code it runs actually removes the codeblocks from the HASH __hEvents so the garbage collector is not blocked by stale object references...

        FOR EACH hEvent IN ::__hEvents
            xKey := hEvent:__enumKey()
            IF HB_ISNUMERIC( xKey )
               hbqt_disconnectEvent( Self, xKey )
            ELSE
               hbqt_disconnect( Self, xKey )
            ENDIF
            ::__hEvents[ xKey ] := NIL            <--- break circular references !!
         NEXT
         ::__hEvents := { => }

This step should remove the need of setParent( QWidget() ) and other strange commands. 

Till this change is made, when using .ui files we should add

   oDlg:exec()

   oDlg:disconnect()

   oDlg:destroy()

C5) You can find all my changes in my branch, named "extreme_playground" :-)))

https://github.com/fperillo/qtcontribs-code/tree/extreme_playground

Note: I didn't find a solution and worked only on composite.prg.

What we should check is the changelog of Qt itself, Qt5.5 is good, Qt5.8 crashes. Which are the changes? Qt5.6 is safe? Qt5.7?

Is Qt5.5 safe because we are lucky? Did they change compiler ? Or the compiler uses a different calling convention, error handling, whatever...

D) QAction compile error

In r485 was added code to create a QAction in a way that was not possibile in Qt5.5 and the code should be guarded with a #ifdef.

I sent a test change in the main thread, did you try it ?

E) QApplication translate...

I could not understand what

F) diffing hbQt with old versions

I created a diff from r485 with the old version I currently use. My hope was to find some deep changes that could explain the crash... you know, a bit changed, a definition in qth, the order of some c statements.

I found nothing of interest, unfortunately

G) the patches you sent

I will have a look later today and create a branch so that they can be visible to everybody in easy way

Francesco

[Zoran Sibinovic]

Hi Francesco,

I wrote only about 4 versions but I built lot more versions from 5.7 forword to 5.15.2 so I did not have time to try Alex getsys suggestion or yours, that will be next.

For now

Your

A) 5.5.1 builds on win10 as win11, you just skipped to say with what version.

B) Interesting what you wrote but can be more specific, what, qtcontribs rev. we talking about and where did you found this patch (some link). This code is not included even in r485.

C) I suppose we talking about composite. If yes, my answer is Yes, sometimes on open and other time on close.

read this may help: 

https://www.google.com/search?q=qt+5.8.+qtcontribs+r485+mingw53-32&sxsrf=ANbL-n7R15rj8V3tz4nxahCfnPyHe2wLWA%3A1781107297849&udm=50&aep=10&ntc=1&mstk=AUtExfBYeWKwyC_HE1bdKySoCR7WuspkJE8wsRjWr_gepdrtpydVauOxr5GwKR7wBKl82Kj-yMfdgHpDQ-qabqfUGO_ZmCkkvM2PWR-ipQszygbub3VgdljWh93tztYmfeTFg5Iixh6kdn4DNGSIT7EMeNEmvqF3s4R9zp6fVrAiejSolFm0-Nn7MjphGAQ-mhY9HUz76bz2Acfkk24THe9JHsOPkKstVN-_gMO1aYIxhoWYzivYt_5GTo9fHYLckbAKu-7J-bPIMmBgjkP9UvZpkwiIyf2aXkeiGI48lcFCjS-aV2l_LgAOoGGPbVrvQnAnL7jcEQ1u5ls9Ow&aioh=3&csuir=1&cs=0&mtid=lYopavqAKLyli-gPqMvdwQ0

I will dig in later.

D) Sorry I did not yet but sure will.
E) neither do I. Seems this code been intended for Qt4 but every ui*.prg have this function in it no matter of the Qt version. The confusion fer me is that it is not compiled for Qt 5.12.12 and Qt 15.2. ... 

F) Keep trying I will also and thing the others will do too.  

G) Thank you.

Best regards

Zoran

[Francesco Perillo]

B) Pritpal commited that patch to hbqt years ago... it removed the flag that tells the compiler to be iso2011 compliant and the comment was "we don't need it anymore".

Then added those lines. Probably 5.8 needs it since mingw5.3 had experimental iso2011 support, perhaps later versions don't need it..

[Zoran Sibinovic]

Hi to all,

Qt.5.9.9, mingw53_32, r485, Alex hbqt_bind.cpp

Validator.prg finally works and not crash on close. On exit the options the object numbers remain the same 11.

omit in line 96 ",GetParent"

  

oWnd:connect( QEvent_Close, {|| HbQtClearGets( oWnd, GetParent ) } )

with

oWnd:connect( QEvent_Close, {|| HbQtClearGets( oWnd ) } )

I hope this will work also for newer Qt versions

Zoran

[Zoran Sibinovic]

Confirmed,

validator works with the above modification also with

Qt 5.15.2, r485 and Alex hbqt_bind.cpp, hbmk2_qt and  hbqt_misc suggestions.

Zoran

[alex;]

Hello, everyone.
There are also hbqtwidgets\tests\pureclip.prg. It causes a crash when closing. I don't know how to fix it yet.

WBR, alex;

четверг, 11 июня 2026 г. в 09:40:31 UTC+3, Zoran Sibinovic:

[Luigi Ferraris]

Il 11/06/2026 11:51, alex; ha scritto:

Hello, everyone.
There are also hbqtwidgets\tests\pureclip.prg. It causes a crash when closing. I don't know how to fix it yet.

Hi to everyone,

I'm not sure, but why not transform the various functions and procedures into a class and then create an object? 
This way, internal variables can be better controlled and perhaps useful for breaking the parentage chain (which is Qt foundamental) when various objects are related to each other. From what I understand, there are at least three objects: a window (with a possible parent), HbQtCalculate, and HbQtBrowse. 
I don't know about the last two, but they could simply be: var m_calculator := HbQtCalculate var m_browser := HbQtBrowse 
This way, a whole series of functions/procedures will benefit from the class variable as "protected method", making the code more controllable and less susceptible to Harbour GC (see unwanted destruction).

I understand that you want to show pure Clipper code, but you have to take into account the Qt world.

Regards, Luigi

[Francesco Perillo]

I created this patch:

https://github.com/fperillo/qtcontribs-code/commit/b2d4abbd9dcd50763ceb03d54da1826d0c78807c

that forces the disconnect at harbour level so that it breaks circular references. The c code was ready but somehow it was never implemented.

Now more objects are correctly deleted and there should be less need for :setParent( QWidget() ) and other strange gimmicks

(to be honest I'd prefer to call the Harbour method but I'm still trying to understand).

This patch will not solve the problems we encounter.

[Zoran Sibinovic]

Hi Alex,

in Qt 5.9.9 it works, from Qt 5.10 and in newer Qt versions crashes but if you exclude the oBrowse object it closes without errors. I will see more later

From Qt 5.10 there are some major changes in Qt and seems that our latest qtcontribs revision doesn't handle (lot deprecations).

Zoran

[Zoran Sibinovic]

Hi to all,

Since we try here various things to solve the problems we face, I suggest some kind of organization.

I suppose that we use, in our production, different Qt versions, qtcontribs revisions and applied patches.

It will be nice if everybody writes in itas post to what environment his discovery applies. ex what Qt, what revision, etc. 

This because Qt made fast changes in its main, minor and sub versions that affects out work even by a sub version so in one version someone's patch/hack work but in the other produce an error.

If we agree that our goal is to reach the latest, at this moment 5.12.2 version we must focus to solve the problems around it. 

If not than please suggest on which version we have to focus and to make us organized.

For me the my last version in use 5.9.9 but I can test quickly 5.12.12 and 5.15.2.

Why to strive towards newer versions? One of the reason is that the Qt documentation changes and introduce its features that not work in the older versions.  

"Why stay to Xp or win7 if we can reach win10 or 11?" 

Thanks

Zoran 

[Francesco Perillo]

I think we should identify which is the first Qt version that crashes and then diffing with the previous that worked.

I use my branch, with my added HB_TRACE and code polishing. I'd like to add a HB_TRACE to every function/method

In composite I only have problems when I open the window and the last line in the log is

hbqt/.hbmk/win/mingw/hbqtgui/QDialog.cpp:239: HB_TR_DEBUG QDialog:exec(07E818A8)

so the crash is in Qt code.

In validator I have another last line but it uses a different way of handling events so it is not comparable,

This evening I will try to switch to the hbQt commit I use with Qt5.5 and see if I can reproduce the crashes.

--
You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/f176e38d-4bf3-43f9-b0bc-8ec329d0c243n%40googlegroups.com.

[Luigi Ferraris]

A little note about B): is many years that I'm using
SET HB_USER_CFLAGS=-std=gnu++11
in my *.bat to build HbQt (I'm using 5.7) 
Regards, Luigi

[Pritpal Bedi]

Hi All

Regression is existance in all versions. Do not focus on any other except 5.8.

As i have explained in numerous times, a dialog created/destructed in succession had this regression present since begining, the mothod to overcome is to create the dialog once, then on close, hide it. Show next time.

I will commit new version shortly.

Pritpal Bedi   a student of software analysis & concepts

http://www.vouch.in   Vouch, the software that GROWS with you

http://sourceforge.net/projects/qtcontribs   HbQt, Harbour bindindings for Qt

http://cacherdd.sourceforge.net   World's First True RDBMS Rdd for (x)Harbour 

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/9548f69a-4efb-49d5-b6e5-323dcae3db4cn%40googlegroups.com.

[Francesco Perillo]

Ok, I did some more tests and probably I found something.

I try to explain, unfortunately my code is quite different from yours so you should replicate from my text

I did compare Qt sources of QDialog between 5.5 and 5.8 with no evidences of big differences in how they are called.  Qt has the QDialogPrivate class where all the dirty jobs are done and I did not compare them.

I traced the events fired, tried several things.

Then I noticed this line:

oDlg := hbqtui_composite()

and in the prg created from the .ui file:

FUNCTION hbqtui_composite( oParent )
   RETURN ui_composite()               :new( oParent )

METHOD ui_composite:init(oParent)

   ::oWidget                           := QDialog( oParent )
   ::Dialog                            := ::oWidget

So, oParent is passed but it is NULL, actually QDialog has no parent. Is it possible, yes, I think it is allowed.

Then I tried to give it a parent and changed composite.prg

   oAct:connect( "triggered(bool)", { || CustInfo(oWnd) } )

STATIC FUNCTION CustInfo(oWnd)

and finally

oDlg := hbqtui_composite(oWnd)

Since this change I was not able to have a crash !

unfortunately my uic_composite.prg is really different from yours (see https://github.com/fperillo/qtcontribs-code/blob/extreme_playground/hbqtwidgets/tests/uic_composite.prg)

and I also don't need :setParent( QWidget() ) anymore

but you may try giving the QDialog a proper parent.

It may be possible, MAYBE, that we do some thing in hbQt that uses a widget parent without checking if the parent actually exists.

Is it possible that mingw 4.92 in Qt5.5 just swallows a null pointer while mingw 5.3 in Qt5.8 throws an exception !

Please let me know

Francesco

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CA%2BeM65xhd38OeJPpdv-fk3q8jHmRBWT-cZ0pMFTxyL2ZuyZenQ%40mail.gmail.com.

[Francesco Perillo]

Please remember that in composite.prg I only get crashes during dialog initialization, never on close (I always use ESC key to close).

I did more than one hundred tests with no crashes.

At the moment, I could not find anything in the code to justify the crash, but I know it is there somehow.... I need to check some ideas...

[Zoran Sibinovic]

Try to close it with the x top right button instead the exit.

_________________________________

 Zoran Sibinović

dipl.menadžer i inž.informatike i statistike

graduate manager and engineer of informatics and statistics

Srbija / Serbia tel.+381 64 1876338

--
You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CADPHLr_wobHX1mW0GrcRg8R3D%3D81Hgnb0u0Td_qt5Z74Nr0XQQ%40mail.gmail.com.

[Francesco Perillo]

Still no problems closing the widow clicking on the X.

Looking at the logs, now that the program doesn't crash, I noticed that the more tests I performed opening/closing the QDialog, more lines were added at the end of the log.

So I added even more HB_TRACEto hbQt and to composite.prg

The logs revealed that when the program was closing and Harbour GC was shutting down, a lot of requests were done to release objects, a number proportional to the times I opened the QDialog... something is not working as expected...

When we create an object derived from QObject wh silently add an "ancestor":

      PHB_ITEM oClass = hbqt_defineClassBegin( "QOBJECT", s_oClass, "HBQTOBJECTHANDLER" );

HBQTOBJECTHANDLER is a Harbour class defined in qtcore/hbqt_misc.prg with some stuff used and some that seems to not be in usebut what interest us now is:

DESTRUCTOR FUNCTION __hbqt_destroy()

The function is defined in qtcore\hbqt_bind.cpp as (simplified)

HB_FUNC( __HBQT_DESTROY )
{
   PHB_ITEM pObject = hb_stackSelfItem();
   if( pObject )
      hbqt_bindDestroyHbObject( pObject );
 }

 So when a Harbour variable holding an object derived from QObject goes out of scope, or set to a different value, the destroyer gets called and finally the call reaches  hbqt_bindDestroyHbObject( pObject)

When in a .prg we create a 

oLabel1 := QLabel( oParent )

oLabel1:setText( "test" )

oLabel1:=NIL

what do you expect ?

Well, since the QLabel() HAS A PARENT when we set the variable to NIL we lose all the references to it by an Harbour variable but the QT object is still alive since we have moved the ownership and the duty of handling its delete to oParent. I don't know how to define this situation with a name, let's call it "Detached from harbour GC", or simply "detached".

When oLabel1 is set to NIL or goes out of scope, it is also removed from the "bind" linked list, whose lenght is the one retrieved by __hbqt_itemsInGlobalList(),

Eache item in this list keeps a reference to the Harbour object, to the Qt object, some flags and ancillary informations, like the type of Qt object.

Ok, so for whatever reason, we ask Harbour to delete oLabel1 and the magic finally happens in   hbqt_bindDestroyHbObject( pObject) !

This function retrieves the "bind" item and then tries to understand what to do. It must remove the item from the "bind list (the harbour variable is being deleted) but what to do with the Qt object?

The logic it performs is clear: if the object is derived from QObject AND the object HAS A PARENT, DO NOT delete the Qt object !

Oooooooooooook ....

So, I repeat, if a Qt object has a parent, hbQt would not delete it !!

No references from Harbour are kept ( "bind" is cleaned ) but the Qt object is present.

So, why we have those logs at shutting down with delete requests ? Because when we did the oLabel1 := QLabel( oParent ) hbQt silently added this connection

QObject::connect( obj, SIGNAL( destroyed(QObject*) ), hbqt_bindGetThreadData()->pDestroyer, SLOT( destroyer(QObject*) ) );

to the QLabel and since we did not delete the Qt object, when everything is hutting down and Qt starts to delete QMainWindow, all its children are deleted, and the slots called.

This SIGNAL is only at Qt level   hbqt_bindGetThreadData()->pDestroyer references  to an instance of c++ HBQDestroyer() that calls hbqt_bindDestroyQtObject

Now, the main question is: why when I open the QDialog with a parent I get no crashes ?

Probably because the QDialog (and its childen? should check...) are never deleted at Qt level, they keep leaking memory but all the references are valid - whatevere those references are !

As soon as I removed the parent, I got my crashes back.

To summarize:

- I was not able to find the real problem

- I added some code to clean the situation when exiting, but it must be revised due to further discoveries

- we need a way to force the delete of a Qt object from a Harbour variable, forse, also if it has a parent() (prabably that :setParent( QWidget()) made the object an orphan

As interesting as it may be, I have to stop now, I have to reorder my ideas....

Francesco

[Zoran Sibinovic]

Hi Francesco,

since is a random crash, my crashes show, sometimes on the opening of the dialog, sometimes on the exit and, more important, with no rules of when it will happen because there is no way to say "on the 3dh opening or 4th exiting it will crash".  

On the 4. of June I consulted AI for this crash and that is what it answers:

The Question: 

qt 5.8.0 and harbour hbcontribs r485, composite.prg chrush randomly on exit the second dialog with Unrecoverable error 6005: Exception error: Exception Code:C0000005 ACCESS_VIOLATION

The answer:

The random crash you are experiencing with composite.prg, Qt 5.8.0, and Harbour hbcontribs (hbqt) is a known issue caused by a double-deletion memory conflict between the Harbour garbage collector and the Qt object tree.
When you close a secondary dialog created via functions like hbqtui_...(), Qt automatically destroys child widgets or handles memory cleanup on its own layout rules. Concurrently, Harbour's garbage collector attempts to release its internal pointer references to the exact same memory space. This timing race causes an ACCESS_VIOLATION (C0000005).

Core Solutions
1. Change the Pointer Disconnect Behavior (Recommended)
You need to explicitly tell Harbour not to automatically destroy the underlying C++ Qt object when the Harbour object goes out of scope or closes.
2. Leverage Qt's Native Deletion Attribute
For helper dialogs that cause random crashes upon destruction, force Qt to manage the lifetime entirely through its asynchronous event loop.
3. Clear Pointer Variables Manually
Before exiting the routine that calls the second dialog, explicitly unbind the UI object and force Harbour to clear the reference safely.

Known Workarounds

Downgrade Qt Build: This problem severely spiked starting with Qt 5.6+ due to modifications in how Qt structures its internal layout tree destruction. Recompiling or linking your application against Qt 5.5.1 typically removes the crash completely without changing a line of code.
Compile with -gc3: If compiling via the Harbour compiler, test with the -gc3 flag to modify how localized blocks manage garbage collection
Because oDlg is generated via Pritpal Bedi's hbqtui_composite() (which loads a structural UI layout tree), Qt maps layout components like oDlg:frameBrowse to oDlg as children. When you manually call :destroy(), Harbour immediately truncates the internal C++ pointer reference, but the event loop (oELoop:processEvents()) is simultaneously trying to close and sweep the window elements. This causes an asynchronous race condition culminating in ACCESS_VIOLATION.

I dont think it is the Pritpal's composite code that is the problem.

According to the above and  since the clue of some aggresive memory handle approach that started from Qt 5.6, 

IMHO, seems we must have some kind of 

IF the object exist,  destroy it ENDIF ...  or

IF pendingdelete = .t.,  do what you have to do ENDIF ...

as low level code adjustment, not in composite. (something like Alex did with his modification in hbqt_bind.cpp)

Zoran

[Francesco Perillo]

No, it is not composite.prg code that creates the problem, I'm sure about this since my actual composite.prg is quite different from Pritpal's, and I still get crashes.

Is it a event loop mismatch in children delete sequence ? It may be. But I get the crash during QDialog opening, not on close.You get at both times.

So we are sure there is a problem, I'm trying to streamline the code and remove all the things that are simply not correct. Or, put it this way, I think are not correct.

Anyway, I created a "zap" function, it forces the Qt object to be destroyed, always, we don't care if there is a parent or not.

Guess it.... now that QDialog are forced to be deleted at Qt level (as they were when I set no parent to them) my composite.prg starts crashing like before.

Anyway, despite the tracing and the changes to the code, when the object are deleted we have the crash. Sometimes.

Now you may ask AI which are the differences in object release between Qt5.5 and Qt5.6+, perhaps AI can give us some ideas....

--
You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/ea310c27-d374-42e0-a5af-f1f79759e891n%40googlegroups.com.

[Zoran Sibinovic]

Hi Francesco,

like I said it above, I dont bilieve that is the composite code.

Here it is my starting conversation with AI regarding your question. I use Google AI mode trough my browser. Open it and go to the top of it

https://www.google.com/search?q=What+are+the+main+differences+between+Qt+5.5+and+Qt+5.6&ie=UTF-8&udm=50&aep=10&ntc=1&mstk=AUtExfAYGcicd1hoiIkXbJUWRHsHj14RGRh7lUG2YvA4lTdZkDkoIoKxpzKmeF-KJB-f1ZjQrNT2tI8gbHMCe8mODWsULI4F9vrnVtTTXcoP9ikw0MSBDOoziVm9OHwSsE_QwTSI1xCMnEGTZiIXZBuF_xSoB5TTjcxScYX8k2tdSbyyTeNrUIU5WqEy9LqzWB0RiUt8E7s3QMjq94MWZBSOUYGfVoHni0y9Q0xD7Boasnyb9y4a8LTrJs0nkLJEycaTgdNsDSwYeSqcg40fgtTZhjK91etrtFrR9wQtdxZuSB_QxkpRlxBmKSvgsFWmHTaxvSqaPdLXj3SA_g&aioh=3&csuir=1&cs=0&mtid=1W8xaruvAt_Bi-gP5fCTsAQ

Zoran

[Francesco Perillo]

We agree: it is not a problem of composite.prg.

But i'm using it as a test bed for the changes inside hbQt.

I studied the code more than I should,.

The problem is clearly inside oDlg:exec()

I think that next step should be to change :exec() with a :show() and a event loop so that we may, I hope, trace what a QDialog really does, step by step.

Tomorrow I will try to install qt on a linux VM, unix dumps are - usually - more easy to read.

I also have an old mac with qt installed, really don't remember which version.

Some more ideas to test but now I think we should go backwards: from the crash dump, to the Qt code and then we should be able to understand what QDialog doesn't like.

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/4a44d431-4119-4c87-833f-f68b00aba097n%40googlegroups.com.

[Francesco Perillo]

I used Qt Creator to debug the application. It should be built with debug libraries and whatever but at the moment please follow me:

Open Qt Creator

Start the composite or validator program 

In Qt Creator, menu "Debug" -> Start Debugging -> Attach to running application.

It will open a form with a list of all the programs executing, locata the one you started and confirm. 

After a few moments the scrren is ready. Debug->Continue (or press F5) and the program can run

open/close the QDialog as you need to get the crash.

You will end with something like in the attached screenshot.

IF I change the order or the number of the objects I always get two lines in the Debugger pane, one is ALWAYS, in my few tests, ZNK17QAccessibleWidget7isValid.

The other line depends on which widgets are compiled.

What is QAccessibleWidget ??????????????

Anyway, please tests with your executables so that you may confirm that the crash happens in the same position, then we may try to understand why

[Zoran Sibinovic]

https://www.google.com/search?q=qacessiblewidget&client=ms-opera-mobile&hs=CSQV&sca_esv=25bb37eb50603e0c&channel=new&espv=1&sxsrf=ANbL-n5IiaOvb0UexFqFtZW2j1gN-FBntQ%3A1781683382886&ei=tlQyat7SNYDvi-gPxNLEmQI&biw=392&bih=679&sclient=mobile-gws-wiz-serp&udm=50&fbs=ADc_l-aN0CWEZBOHjofHoaMMDiKpmAsnXCN5UBx17opt8eaTX-iVZ7JibxEA2X7M_ninQtzlFCCzIlNFqkxF8jx6Oj4HIdodquR-Qu42j5eXHyNB3H7mplsixu1xvrs7P_B4FUG7M7bNSgq5FhyBXhGHAl8SROx-OSqko_uqXJN3hjlwh8CENJ-p8xPqHHdiRfXRHI9Zj8p72j4uZit_fUWAA7daVFs4iQ&aep=10&ntc=1&mstk=AUtExfAJeRY-UtNXRKUJfpg2VINiQXNUPHXfmhB7XMckAiTCZRCnsfaC4Eq5kyUAHRcdVSs-KVqpyma7-co7NnjSrl83w4teoi5MIFfO4vxvyR6Icqqa7pLOndo_6VOj_eeAMbXj428170fPslKlZtKtIILwvKpOYY7uk5yC39PxtaSzI6BBg4D2dNDpC3j3O5tBy4ur20NILYYSN8btN8gFgCIPcCExlva8jJ8BVzbJOI5--s0fUkcrWeJapsdVKQ-KmaTcbZ0JVleFnwjg74O8ZNmeOPJbVZG3v-UBpNI72XgAdng37Rhv-ZjLebpDCGuXmKY-R9LPvkW_EOy47F4hXl0YLKPg11XpFqhf_cvg6uPZG0NQDR98GcStbNU4-7U1cgRqfaAjMCHrDGMVt92MjQXNV5ec3wKMRSo0sU-TjpMqbAKJOzzNoi0g_m-w9t4HzHIv8jN6Es4&csuir=1&aioh=3&mtid=-lQyaq_jI7S9i-gPytqB0AY#lfId=ChxjMe

_________________________________

 Zoran Sibinović

dipl.menadžer i inž.informatike i statistike

graduate manager and engineer of informatics and statistics

Srbija / Serbia tel.+381 64 1876338

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CADPHLr__Yi66THXi4wUd56yajxAYP%2BV4qpJJcZLBP24AWHJxww%40mail.gmail.com.

[Zoran Sibinovic]

A SIGSEGV (Segmentation Fault) in a 32-bit MinGW environment usually indicates a memory access violation or a severe debugger/library mismatch when mixing legacy C++ stacks like Harbour with Qt components.
Resolve and isolate the exact cause using these targeted steps:

1. Check for Memory Corruption in your Harbour + Qt Code
Most SIGSEGV signals trace back to application bugs.
Uninitialized Pointers: Check your Harbour and C/C++ FFI code to ensure pointers are properly initialized before access.
Mismatched Free/Delete: Ensure memory allocated in Harbour is freed safely, and C++ pointers deleted with the correct operator (e.g., delete vs delete[]).
Stack Overflow: Excessive recursion or large stack allocations in your Harbour code can corrupt memory.

2. Isolate the Debugger & Environment
Enable Qt/C++ Debug Symbols: Ensure your Build Configuration is set to Debug and that your build files correctly include -g or -ggdb in QMAKE_CXXFLAGS.
Inspect the Stack Trace: When SIGSEGV occurs, dismiss the initial alert and immediately open the Debugger view (Views > Stack). Look for the last valid function called in your code to pinpoint the exact line causing the crash.
Bitness Mismatch: Ensure you are running 32-bit Qt Creator. If your Qt Creator is 64-bit and your kit is 32-bit MinGW, the GDB debugger may throw emulated memory exceptions. Match the IDE architecture to your kit architecture.

3. Diagnose qtcontribs and Harbour Interaction
Library Mismatch: Check if the Harbour qtcontribs binaries were compiled with the exact same MinGW version as your Qt installation. Mixing MinGW-builds with MSYS2-builds can cause immediate segmentation faults.
Symbol stripping: Pre-compiled Harbour libraries sometimes do not include debug symbols.

[Zoran Sibinovic]

Question: "What and where you suggest to look in harbour?"

Answer: To find the cause of a SIGSEGV within the Harbour layer, you need to focus on how Harbour handles memory management, variable scopes, and its C-API bridging.
Here is exactly what and where to look in your Harbour code and runtime environment:

1. The Garbage Collector (GC) and Object Scopes
Harbour uses automatic garbage collection, while Qt relies on its own parent-child object hierarchy. When these two systems conflict, a SIGSEGV happens.What to look for: Look for LOCAL variables holding Qt widgets that are created inside a function but passed to a persistent event, signal, or layout.
The issue: When the Harbour function ends, the LOCAL variable goes out of scope and the Harbour GC might destroy the wrapper, but the Qt side still tries to access it later.
Where to look: Change critical UI variables from LOCAL to STATIC or attach them directly to a persistent window object to prevent early garbage collection.

2. The qtcontribs Pointer Cache
qtcontribs maps Harbour objects to C++ pointers using an internal item cache.What to look for: Look at where your application closes windows, destroys widgets, or dynamically updates layouts.
The issue: If a C++ pointer is deleted on the Qt side, Harbour might still hold a reference to that memory address. Accessing it next time will immediately trigger a SIGSEGV.
Where to look: Check your hbqt code for double-deletion or missing oWidget:end() calls. Ensure you are not manually deleting widgets that already have a Qt parent (as the parent handles destruction).

3. Harbour C-API Parameter ValidationWhat and where you suggest to look in harbour?
If you wrote any custom C-code wrappers or modified qtcontribs, the Harbour C-API (hb_par... functions) is a prime suspect.What to look for: Look for functions like hb_parptr(), hb_parnl(), or hb_parvc().
The issue: If the Harbour code passes a NIL or unexpected data type to a C function, and the C function assumes it is valid without checking, it will dereference a null pointer.
Where to look: Ensure every C function uses validation macros, such as checking if a pointer is null before passing it to Qt:

c (not c++)
PHB_ITEM pItem = hb_param( 1, HB_IT_POINTER ); 

if( pItem ) { 

// Proceed safely

[Francesco Perillo]

Hi Zoran,thank you for this answer but unless you have accesso to some more powerfull AI that can analyze the code, this generic answers won't help.

I did investigate almost all the points listed by AI. I may have overlooked some issues, I'm far from a perfect programmer....

We have a random crash, at random times, and in internal Qt code that references objects created from harbour but that - from the tracing logs - are not modified nor deleted after being created. If deleted, Qt would know...

So please, can you perform the steps I listed above with QT Creator ? Can you confirm the program crashes there ? 

I was not able to find how to disable accessibility....

trying to link to debug libs now...

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/0396cb2a-5f91-41f1-a625-ac564c1be7c5n%40googlegroups.com.

[Zoran Sibinovic]

Hi Francesco, I will 

_________________________________

 Zoran Sibinović

dipl.menadžer i inž.informatike i statistike

graduate manager and engineer of informatics and statistics

Srbija / Serbia tel.+381 64 1876338

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CADPHLr-DWwM72B4NW49J%3D%2BfXzagaSvNg_wU7ertACDjk6p77jw%40mail.gmail.com.

[Francesco Perillo]

Here is the stack trace of my crashes....

So it seems to be a QScopedPointer going bad.

Really interesting following the code:

this is real Qt5.8.0 Qt source code:

bool QAbstractButton::isCheckable() const
{
    Q_D(const QAbstractButton);  <--- line 602
    return d->checkable;
}

According to https://wiki.qt.io/D-Pointer

#define Q_D(Class) Class##Private * const d = d_func()

and we have the call to d_func()

that finally reaches:

qglobal.h:961

template <typename Wrapper> static inline typename Wrapper::pointer qGetPtrHelper(const Wrapper &p) { return p.data(); }

And in qscopedpointer.h:140

    T *data() const Q_DECL_NOTHROW
    {
        return d;   <---line 140
    }

So, ok, there is a pointer that is no longer valid - and we knew that.

But I can't understand why...

[Francesco Perillo]

I did some more tests and found - and hopefully fixed - some more memory leaks.

But the crashes still happen.

Since everybody agree that there should be a memory corruption somewhere in the code, I tried to follow the code flow adding tons of HB_TRACE and look for memory leaks and pointer mishandling, despite the fact that all my crashes are always in a specific code path of Qt internals.

As I reported in a previous message, if a Qt object has a parent, when the Harbour object is deleted, they are detached/unbinded so that Qt object can still live according to Qt  object life cycle.

We get notified that an objet has been deleted by Qt via the "destroyed()" signal.

So, if Qt deletes an object we call hbqt_bindDestroyQtObject. (https://github.com/fperillo/qtcontribs-code/blob/master/hbqt/qtcore/hbqt_bind.cpp line640) where we stop all the signal/slot and remove the eventFilter if installed.

Well, we stop signal/slot but we don't take care of the slots !

I'd like to write all the steps but I have no time now and go to the end. 

When we have a line like this 

   oDlg:btnOpt1:connect( "clicked()", {|| oDlg:labelTitle:setText( "Option 1 Clicked" ) } )

actually happens this in HBQtObjectHandler class (https://github.com/fperillo/qtcontribs-code/blob/master/hbqt/qtcore/hbqt_misc.prg):

::__hEvents[ "clicked()" ] = "clicked()"

::__Slots[ numericIdOfSignal("clicked()")] = a reference to the codeblock

The function hbqt_bindDestroyQtObject completely ignores these hashes and they are not cleaned, so the references to the codeblock stay alive. I added code for removing them as cleanly as possible but when the destroyed signal is called, it is just a few cpu cycles before deletion and several steps are already done by the constructor.... simplyfing a lot, I wanted to to backwards what a connect() does so imagine doing a 

sort of for each value of __hEvents, do a ::_Slots[ numericIdOfSignal( vlaue ) ] = NIL but at the end I had to just iterate on each item of ::__Slots and setting them to NIL.

While I was writing this note, I changed one line in my composite.prg and.... the program stopped working ! Selecting "Customer info" menu did not open the QDialog. I had to dig inside the metacall handler and finally solved changing from

paramString.isNull()

to

paramString.isEmpty()

in hbqt_hbqslots.cpp

PLEASE NOTE:

I still get the crash but read carefully what I'm writing:

I don't get the crash (up to 50 opening /closing of the QDialog) is I add this command:

oDlg:setparent( QWidget() )

But in my code oDlg is still a object BUT has no Qt object binded. So the code flows here:

/* void setParent ( QWidget * parent, Qt::WindowFlags f = 0 ) */
HB_FUNC_STATIC( SETPARENT )
{
   QWidget * p = ( QWidget * ) hbqt_par_ptr( 0 );
   HB_TRACE( HB_TR_DEBUG, ("QWidget (%p):setParent", p ));
   if( p )

but p IS NULL and no code is executed. It should be reported as an error, but there are no such errors in hbQt....

So actually the method does nothing BUT we have created and then destroyed a QWidget... and this fact has changed something in the GC/memory stack.

[Francesco Perillo]

Please try to start your program with this setiting:

set QT_STYLE_OVERRIDE=fusion

I asked Teo for some help, and he agrees that the problem arises from a NULL/invalid  pointer inside Accessibility code in Qt.

there should be a setting QT_ACCESSIBILITY=0 to diable tit but it changes nothing.

Teo noticed that the Fusion style doesn't query for accessibility stuff, I tried and.. .I was not able to have a crash.

So, since my crashes may be different from yours, please use this setting and do some tests.

GUI graphic will be a bit different, but we are testing reliability now

It would be also nice if you could attach the debugger of Qt Creator to your program and report the stack when it crashes.

Francesco

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/4a44d431-4119-4c87-833f-f68b00aba097n%40googlegroups.com.