Unrecoverable error 6005: Exception error: Exception Code:C0000005 ACCESS_VIOLATION

[Zoran Sibinovic]

Hi to all,

time ago I started this problem.

I thought that maybe it was solved whit the latest revisions due to how the classes are handled but, the problem still appears.

For those  who are not familiar with the problem I will explain it again.

I use Windows no matter the version, the issue is the same, and appears on different computers also.

With the 5.6.0 version of Qt, every dialog created with oDlg := hbqtui_...() cause the app termination with the described errors in the logs attached to this post.

The app that can be used for the test is composite.prg from the tests folder

The issue can be provoked  by opening and closing the "Customer info" menu item. The number of open/close times, till the termination succeded is random, sometimes 5-6 sometimes more, but everytime terminates with the crash of the entire app.

The Qt 5.5.1 version is the latest with which everything works normal.

I read the What's new about the Qt 5.6 version at: 

https://doc.qt.io/qt-5/whatsnew56.html#:~:text=Improved%20cross%2Dplatform%20OpenGL%20ES,with%2016bits%2Dper%2Dcolor.

and seen that they changed something about the memory usage, the GUI, etc.  

This is my environment sets for Qt 5.6.3:

SETX -m HB_QT_MAJOR_VER "5"
SETX -m HB_QT_MINOR_VER "5"
SETX -m HB_INSTALL_PREFIX "c:\hb"

SETX -m MGWHOME     "c:\Qt\Qt5.6.3\Tools\mingw492_32"
SETX -m MGWBIN      "c:\Qt\Qt5.6.3\Tools\mingw492_32\bin"

SETX -m QTHOME      "c:\Qt\Qt5.6.3\5.6.3\mingw49_32"
SETX -m HB_QTPATH   "c:\Qt\Qt5.6.3\5.6.3\mingw49_32\bin"
SETX -m HB_WITH_QT  "c:\Qt\Qt5.6.3\5.6.3\mingw49_32\include"
SETX -m QTPLATFORMS "c:\Qt\Qt5.6.3\5.6.3\mingw49_32\plugins\platforms"

REM c:\hb
REM c:\hb\bin\win\mingw
REM %MGWHOME%
REM %MGWBIN%
REM %QTHOME%
REM %HB_QTPATH%
REM %HB_WITH_QT%
REM %QTPLATFORMS%
REM - added directly in OS environment parameters PATH 

So did I missed something?

Thanks for every answer.

Zoran

[Pritpal Bedi]

Hi Zoran

I never recommended 5.6. Use either 5.5 or 5.8 where I do not see any crash.

Pritpal Bedi

a student of software analysis & concepts

[Zoran Sibinovic]

Hi Pritpal,

thank you for this tip I didn't know about this.

One thing more, did I have to add some additional environvent parameters to mine above descripted to make work the 5.8 version and that are not been required for the 5.5 version?

Thank you again

Zoran

[Zoran Sibinovic]

Hi Pritpal,

I compiled harbour and Qtcontribs with Qt 5.8.0 with this environment parameters ...

SETX -m HB_INSTALL_PREFIX "c:\hb"

REM /*----------------------------------------------------------------*/
REM ....... Qt settings
REM /*----------------------------------------------------------------*/

SETX -m QTROOT       "c:\Qt\Qt5.8.0"
SETX -m QTHOME      "c:\Qt\Qt5.8.0\5.8\mingw53_32"
SETX -m QTBIN           "c:\Qt\Qt5.8.0\5.8\mingw53_32\bin"
SETX -m QTINC           "c:\Qt\Qt5.8.0\5.8\mingw53_32\include"

REM /*----------------------------------------------------------------*/
REM ....... MINGW
REM /*----------------------------------------------------------------*/

SETX -m MGWHOME     "c:\Qt\Qt5.8.0\Tools\mingw530_32"
SETX -m MGWBIN          "c:\Qt\Qt5.8.0\Tools\mingw530_32\bin"

REM /*----------------------------------------------------------------*/
REM ....... required
REM /*----------------------------------------------------------------*/

SETX -m HB_WITH_QT      "c:\Qt\Qt5.8.0\5.8\mingw53_32\include"
SETX -m HB_QTPATH       "c:\Qt\Qt5.8.0\5.8\mingw53_32\bin"
SETX -m HB_QT_MAJOR_VER "5"
SETX -m HB_QT_MINOR_VER "8"
SETX -m HB_USER_CFLAGS  "-std=gnu++11"

SETX -m QTPLATFORMS     "c:\Qt\Qt5.8.0\5.8\mingw53_32\plugins\platforms"

REM c:\hb; c:\hb\bin\win\mingw; %MGWHOME%; %MGWBIN%; %QTHOME%;  %HB_QTPATH%; %HB_WITH_QT%; %QTPLATFORMS% (directly added in OS environment parameters PATH) 

... and still got the hb_out in the attachment after open/close "Customer info" in composite.exe ...

this happened after at the 7-th consecutive dialog opening ... but it is a random opening number

I really don't understand what I'm doing wrong.

Thanks

Zoran

[Pritpal Bedi]

Hi Zoran

I could reproduce the error - after 17 iterations it booms. Will see what can be done to handle such situations.

Pritpal Bedi

a student of software analysis & concepts

[alex;]

Hi, Zoran.
I  reproduce the error on version 5.15.2 on Windows 10.
How to find log in my system?
Are you still using 5.5.1?

WBR, alex;

вторник, 23 мая 2023 г. в 12:23:50 UTC+3, Zoran Sibinovic:

[Zoran Sibinovic]

Hi Alex,

I stayed at the 5.5.1 version till today.

I tried for several times various newer versions and their updates but without any success.

Sorry

Zoran

[alex;]

I think AI can help solve this problem.
I'll have to try it later.

WBR, alex;

понедельник, 25 ноября 2024 г. в 11:10:07 UTC+3, Zoran Sibinovic:

[alex;]

Hi, Zoran.
I'm on vacation. ))

I added next code in hbqt_bind.cpp

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

#include <QtCore/QFile>
#include <QtCore/QTextStream>

...

int __hbqt_bindItemsInGlobalList( void )
{
   QFile logFile("output.log");
   logFile.open(QIODevice::WriteOnly | QIODevice::Append);
   QTextStream stream(&logFile);

   stream << "Begin" << Qt::endl;

...

stream << "_____Items #" << i << "______(" << bind->szClassName << ")" << Qt::endl;

...

 logFile.close();

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

and got next results:

1. on init

Begin
_____Items #1______(HB_QEVENTLOOP)
_____Items #2______(HB_QACTION)
_____Items #3______(HB_QWIDGET)
_____Items #4______(HB_QMAINWINDOW)
_____Items #5______(HB_QFONT)
2. after close second dialog

_____Items #1______(HB_HBQPROXYSTYLE)
_____Items #2______(HB_QEVENTLOOP)
_____Items #3______(HB_QACTION)
_____Items #4______(HB_QWIDGET)
_____Items #5______(HB_QMAINWINDOW)
_____Items #6______(HB_QFONT)

I see that added HB_HBQPROXYSTYLE

what is it?

what do you think?

WBR, alex;

понедельник, 25 ноября 2024 г. в 11:10:07 UTC+3, Zoran Sibinovic:

Hi Alex,

[Zoran Sibinovic]

Hi Alex, I don't know either. I found in https://doc.qt.io/qt-6/qproxystyle.html that is something that regards the displyed style. Sorry if it can't help you

--
You received this message because you are subscribed to a topic in the Google Groups "QtContribs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qtcontribs/wSWZGBGdicw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qtcontribs+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/aaab32d1-7d2f-420c-8a20-20e1a545b980n%40googlegroups.com.

[alex;]

Hi, Zoran. I've posted some ideas here. https://groups.google.com/g/harbour-users/c/3dFu8qu7iUM

среда, 14 мая 2025 г. в 08:22:41 UTC+3, Zoran Sibinovic:

[Francesco Perillo]

Please follow my reasoning.

hbqtui_* functions are included in .prg files created on the fly during the compilation process.

If you open one of these generated files you will see that follow the same skeleton and we are interested in the destroy() method.

METHOD ui_hbpdbstruct:destroy()
   ::groupBox                          := NIL
   ::label                             := NIL
   ::editName                          := NIL
   ::label_2                           := NIL
   ::comboType                         := NIL
 

I ask you to retrieve the generated .prg file of the form you have problems with, copy it in your main directory and in the .hbp change the reference from the .ui file to this .prg.

In this way you are compiling a source file like many other but you can make changes AND ADD TRACING LOGS!

As you can see  the first item to be destroyed is the groupBox, the container ! Qt should recursively destroy all the children items but it may do it in a different order in different Qt versions and this may create the problem !

If I were in your place, I'd change the code to:

METHOD ui_hbpdbstruct:destroy()

log ("before groupbox")

   ::groupBox                          := NIL

log ("before label")

   ::label                             := NIL

log ("before editname")

   ::editName                          := NIL

trying to locate the exact moment  the fault appears.

I also have mixed feelings about

  ::oWidget                           :setParent( QWidget() )
   ::oWidget                           := NIL

 

It has been a long time since I had a look at hbqt internals and may have wrong memories.

I'd work on this file commenting all the code of the destroy() method.

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/ef2841b4-b291-4527-a918-960ce76b4da6n%40googlegroups.com.

[alex;]

Hi, Francesco.
It seems to me that the objects are being destroyed, but the references in the HBQT_BIND structure are not being deleted.
WBR, alex;

суббота, 17 мая 2025 г. в 11:28:19 UTC+3, Francesco Perillo:

[Francesco Perillo]

When a widget is created by the hbQt layer, we register a sort of callback when the Qt object is about to be deleted.

A lot of man hours were used to create a system that can resist to unexpected order of object destruction, both when solicited from c++ or HbQt.

I haven't seen your code. You reported the following log lines, with HBQProxyStyle not deleted... this object is not handled by the automatic deletion of the objects.

It is used twice in hbQt code, one is in hbqt\tests\demoqt.prg. Can you please try this demo ? I tested it with qt 5.5 and it works.

It is also used in the alternative getsys system. but I didn't test it.

Are you using HBQProxyStyle ? Are you using the getsys included in hbQt ?

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/e655ef52-295c-47c9-8dc7-467b4635b593n%40googlegroups.com.

[Luigi Ferraris]

Hi Alex

As @Francesco writes, adding my little experience

::oWidget:setParent( QWidget() )

You can also use ::oWidget:setParent(0) to detachs object from its parent at Qt level

and than ::oWidget := NIL, but sometime is not enough.

The objects you see in your log, AFAIK are UNdestructed objects IOW already alive from HbQt (.PRG) perspective.

Regards

Luigi

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

--

Luigi Ferraris
www.l3w.it

[Francesco Perillo]

I read again the thread and found the reference to the composite.prg demo. Unfortunately I only have Qt 5.5.0 installed so I can't try with new versions.

The demo - as its name implies - mix standard Qt widgets created by the hbqtui_composite() functions, other hbQt objects added at runtime and, more important, objects related with the GET system created by Pritpal.

The outcome is the following:

When I first start the demo I see in the title bar that there are 5 objects created. Open the menu, 101 objects, close the form, 6 objects..... probably that HBQPROXYSTYLE. Open the form again: 100 objects... why one less ? 6 100 6 100 6 100 the values don't change anymore.

With this new knowledge I'd start debugging removing any reference to HBQPROXYSTYLE from hbqtwidgets\getsys.prg It is used only for cursor width (insert vs replace editing)

If the problem persists, it is not HBQPROXYSTYLE fault and we should explore other ways to find the bug.

[alex;]

Francesco,  you're right. I was thinking of moving in that direction too. I think QPROXYSTYLE was added to use an alternative style. For example, the gradient for the Qlabel in composite.prg.

WBR, alex;

воскресенье, 18 мая 2025 г. в 14:18:36 UTC+3, Francesco Perillo:

[Zoran Sibinovic]

Hi, It's an old problem topic that I started. Till now you can use at last the 5.5.1 version without this issue. All the newer versions produce this error. Till now the solution is not founded.

_________________________________

 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/f020e3ae-9549-4ee6-96e3-1c2fd268c412n%40googlegroups.com.

[alex;]

In addition,
I have entered
!analyze -v
in WinDbg and returned the results of the crash analysis to Copilot.

The call stack shows that the call goes through QAbstractButton::isCheckable, then QStyleHelper::isInstanceOf, and then through QWindowsVistaStyle::DrawPrimitive.

So yes, I think the problem is with the styles.

WBR, alex;

воскресенье, 18 мая 2025 г. в 14:32:23 UTC+3, Zoran Sibinovic:

[alex;]

Copilot again:
That's the key problem! If ::style:parent() is NIL, then Qt does not manage the lifetime of HBQProxyStyle, and it remains in memory after the form is closed. In Qt, QObjects that do not have a parent are not deleted automatically, they need to be deleted manually.

воскресенье, 18 мая 2025 г. в 14:39:26 UTC+3, alex;:

[Francesco Perillo]

Ok, I see a little difference between the code generated code of QLabel and HBQProxyStyle

   hb_itemReturnRelease( hbqt_bindGetHbObject( NULL, pObj, "HB_QLABEL", hbqt_del_QLabel, HBQT_BIT_NONE | HBQT_BIT_OWNER | HBQT_BIT_QOBJECT ) );

   hb_itemReturnRelease( hbqt_bindGetHbObject( NULL, pObj, "HB_HBQPROXYSTYLE", hbqt_del_HBQProxyStyle, HBQT_BIT_NONE | HBQT_BIT_OWNER ) );

Looking at hbqt\qtcore\hbqt_init.cpp this missing flag may explain the missing DELETE.

QProxyStyle is derived from a QObject as we may clearly see here: https://doc.qt.io/qt-6/qproxystyle-members.html

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/a73b5d97-6680-439e-90a6-b33554b3ff2bn%40googlegroups.com.

[Francesco Perillo]

I can't understand why Qt should call DrawPrimitive when closing the application !!!???

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/d9deb114-7935-4ea5-82ee-286597f641den%40googlegroups.com.

[alex;]

If click on buttons and them to close dialog, then will be 30 active objects.

воскресенье, 18 мая 2025 г. в 15:52:23 UTC+3, Francesco Perillo:

[Luigi Ferraris]

I believe HbQt suffers from two problems:
   1) that Qt is constantly changing and
   2) the desire to use Qt with Harbour as soon as possible.
   
AFAIK there are 3 great family of Qt objects:
   a) not derived from QObject
   b) derived from QObject
   c) derived from QWidget
   
From my POV, each of these needs to have its counterpart in the HbQt world.

If you write a C++ class and it contains e.g. m_icon = QIcon, you need to "manualy" delete

m_icon otherwise memory leak occurs.

Next are only simple code to explain my bad English

So, 1st HbQt class may be
CLASS HbQtAnyHandler
   ACCESS pointer                               INLINE ::pPtr
   METHOD HbClean
METHOD hbClean() CLASS HbQtAnyHandler
   // do something at CLipper level
RETURN self

2nd HbQt class (+- like current) QObject derived
CLASS HbQtObjectHandler INHERIT hbQtAnyHandler

3d HbQt class QWidget derived
CLASS HbQtWidgetHandler INHERIT HbQtObjectHandler

As you can see, the HbClean method can be used to place your code as
   ::m_icon1 := NIL
   ::m_translator := NIL
   in any CLipper class/object
   
Other big problem (a lot of thread exist): iheritance, Qt parent/child chain, Clipper var out of scope
If you write your own class myWidget with additional methods (and vars), than code
   LOCAL window, dummy
   window := QMainWindow()
   window:setCentralWidget( myWidget( window ) )
   dummy := window:centralWidget()
Probably, you get back an object with class "QWidget" instead of "myWidget".

So you need to code
   LOCAL window, m_central
   window := QMainWindow()
   m_central := myWidget( window ) N.B. but now you have a CLipper var/object alive
   window:setCentralWidget( m_central )
   dummy := window:centralWidget() <== so it's unuseful because you have m_central
in many circumstances (expecially in your project classes) you must code
   m_central := NIL where?

and if you code
   LOCAL window, m_central, dummy
   window := QMainWindow()
   m_central := myWidget( window )
   window:setCentralWidget( m_central )
   m_central := NIL
   dummy := window:centralWidget() what you get?
   

Third an last AFAIK we cannot "emit signals" and sometimes is or may be usefull.

I don't have a good skill or a good knowledge of C/C++ in Harbour and Qt otherwise I would try to implement it

So, your problem (probably) is due to missing code as Francesco writes but take in account these warnings

Regards

Luigi