Called object is not of the correct type (class destructor may have already run) - what is it? o.o

[Dariusz]

Hey

The app works fine on windows, but on MAC its fun stuff... I keep getting this >

Called object is not of the correct type (class destructor may have already run)
When I set it on QComboBox->setIndex(1)

I'm puzzled :/

[JonB]

@Dariusz
You have a (pointer) variable named QComboBox when the class is named QComboBox?

My guess is this is a runtime error message when QComboBox does not point to a still-live QComboBox?

[mrjj]

@Dariusz said in Called object is not of the correct type (class destructor may have already run) - what is it? o.o:

Called object is not of the correct type (class destructor may have already run)

please show the real actual code as QComboBox->setIndex(1) seems wrong due to the var name.

[Dariusz]

Hey
@JonB Its definitely alive, it runs fine on windows, and when I debug it I can see item with valid data/etc. & its QComboBox
@mrjj Sorry my bad! Its> setCurrentIndex.

I've removed it now to "skip the crash" to test more and I crashed again on another thing totally. Mac... fun time.
It feels like calling a slot on Qt item can cause explosion...
Here is screnschot of comboBox trace log >

I'm lost, trying to dig through it somehow.

Ok I'm closer to answer...
I cant do this >
connect(mRange, static_cast<void (QComboBox::*)(int)>(&QComboBox::currentIndexChanged), this, &icCurveWidget::pushUpdate);
My "new" signals breaks I have to revert back to old(sender, SIGNAL() , this,SLOT()); :- (((( no idea why the new ones wont work for me:/

This object is made by a dylib plugin that creates view, which is a static library imported to main app that imports dylib. I wonder if I need to add some kind of... export macros hmmmmmmmmm

[JonB]

@Dariusz
In have no idea what you are trying to achieve. But if you static_cast<> and that is wrong (not of the type you tell the compiler it is) then could cause the kind of error you reported. Why are you using any kind of static_cast?

[mchinand]

Use qOverload instead of static_cast. See Selecting Overloaded Signals and Slots

[Dariusz]

Hey

Yeah thats a crazy one overload, looking at data years old so uhh my bad!

Fixing it sadly did not help, another signal/slots screams here >

This crash > connect(addItem, &QAction::triggered, this, &icCGraphicsScene::addItemPoint);
This works > connect(addItem, &QAction::triggered, this, [this]() { this->addItemPoint(); });
Yes I know the "works" one is not good, but I simply cant connect normal signals on M1 mac. Maybe its ARM issue ?

[JonB]

@Dariusz
If somebody can help further they will surely want to know what version of Qt you are using and what kind of MacOS version?

[Dariusz]

@JonB 6.3.0, MacOS Monterey 12.4 (21F79). Mac M1 Mini.
I've had this problem for year + now I think.

Cant signal slot 50% of my connections for some reason.

Just did not know that this error is this. I usually fix it via either old SIGNAL(), SLOT() connection or lambda :/

[JonB]

@Dariusz
...and then someone will ask whether you can produce any one minimal example which shows this problem for you, so they can actually try it...? :)

[Dariusz]

@JonB Its been on my todo list for a year :- )

I will eventually make it...

I'm sorry, its topic repeat, I know the answer is null till I post a git project that can reproduce it, its just lots of work to do it :D
I just didn't realise it was signal error again, sigh.
Sorri, & thank you for help <3
Regards
Dariusz

[KroMignon]

@Dariusz said in Called object is not of the correct type (class destructor may have already run) - what is it? o.o:

Hey
Yeah thats a crazy one overload, looking at data years old so uhh my bad!
Fixing it sadly did not help, another signal/slots screams here >
This crash > connect(addItem, &QAction::triggered, this, &icCGraphicsScene::addItemPoint);
This works > connect(addItem, &QAction::triggered, this, this { this->addItemPoint(); });
Yes I know the "works" one is not good, but I simply cant connect normal signals on M1 mac. Maybe its ARM issue ?

DISCLAIMER: I have never developed Qt application for Mac (or used a Mac).

My guess is that you have an issue on instance class life cycle.
When creating a lambda function, the captured variables are copied.

But this is just a fealling...

[Dariusz]

@KroMignon I'm back to this hell of an issue :- D

Nope live-time is not the problem. Both objects are alive.

Seems like he can't resolve signals/names somehow properly.
Perhaps its my namespace.
Or ARM
Or there is some build flag I'm missing.

I just did big update to my UI library, everything works on Windows, but I go to MAC and he ignores all signal/slots connections, or most of them. I'm linking against static .a library creating dylib one and loading it in my app at runtime.

At some point Qt for mac fails in my crazy build :/

I have to redo all my signals now from signal>signal or signal>slot connections to signal>lambda ;/////

qOverload sadly does not work either.

QLineEdit will just crash (or my customLineEdit) and QCheckBox will just "not work".

im on 6.5 Qt btw. moved from 6.1 I think.

[Marcus Tillmanns]

@Dariusz
I'm having the same issue (also M1 mac, haven't tried on other platforms yet). The problem seems to be that inside Qt code, the call to call dynamic_cast<>() fails for my object, even though it should work. The target class that it cannot dynamic_cast to is defined in a static library. When I change it to a dynamic library instead, everything works fine.

Did you have any more luck in the mean time?

[J.Hilk]

@Marcus-Tillmanns interesting, I'm personally using a mix of static and dynamic libs (all qt based) on Mac and everything works just fine.

But I'm also using 5.15 and not Qt6

[SGaist]

@Marcus-Tillmanns hi,

Any chances you are using plugins in your application ?

[dantti]

This is not related to ARM/Mac whatever, nor will happen before Qt 6.3.

The issue is that in 6.3 there's now an assert that checks if the receiver object and method "match", it works with lambdas as it's either incomplete or impossible to check because lambdas aren't part of the receiver type.

This happened to a code I replaced the old syntax and the issue was that some Parent class while destroying children of of them, had a signal being emitted on destructor, that called some functions and emitted back to the half destructed Parent hitting the assert.

What I did was to queue one the signals to allow the destructor to finish.

[Vinny_Jones91]

@SGAIST hello.

I've encountered the same issue with Qt6.6.2 and yes, we're using plugins in our macOS application.

Looks like dymanic_cast fails to work correctly across dylib boundaries.
-flat_namespace compile option helps with dynamic_cast itself (and so, fixed the mentioned assert), but causes other issues for us.

If you could share any thoughts on how this may be fixed, that would be much appreciated.

[SGaist]

@Vinny_Jones91 hi and welcome to devnet,

Any chances you are using static libraries to build your plugins ?

[Icaro]

I had a similar issue and @SGaist question actually helped me.
My code was hitting the "called object is not the correct type class destructor..." assertion and I changed the library from static to dynamic and now it seems to work properly on MacOS.
Not sure what the issue is or if it is a bug that is already solved in more recent versions (I am currently using Qt6.4.2) but I will go for the dynamic library solution for now so I can move forward.
Thanks!