Failing qobject_cast

rcari

That was my point however, some compiler magic could lead to cases where it wouldn't even lookup the vtable to place the call for metaObject(), thus not requiring to dereference the pointer... I agree that would be serious trickery...

Franzk

Hmm, well spotted. I think you need to dig into the qobject_cast to see what's going wrong.

goetz

Is the Surface_mesh class based on QObject too?

And what is the output of this snippet:

@
const QMetaObject *mo = model->metaObject();
while(mo) {
qDebug() << mo->className();
mo = mo->superClass();
}
@

tallia1

I just spent my morning trying to figure it out. Indeed rcari
is right, I didn't need to to qobject_cast. I was using it mostly
because I wanted to use introspection to see whether I was
doing something wrong...

An important note is that the two classes are located in
different dynamically loaded libraries... so I am not sure
I can use the C++ dynamic_cast there...

I will try what you suggest Volker.

goetz

qobject_cast should be safe over DLL boundaries - that's at least what the docs state. You did not answer whether the Surface_mesh class is based on QObject too?

tallia1

Hi Volker,

Indeed, that's why I was using qobject_cast at a certain point (and going back to it right now)

And to answer your question, yes it is:
@
class SurfaceMeshModel : public Model, public Surface_mesh{
Q_OBJECT
Q_INTERFACES(Model)
...
@

goetz

That was clear, SurfaceMeshModel inherits Model which eventually inherits QObject.

The question is, does your second base class, Surface_mesh, inherit QObject too (directly or indirectly) - i.e. what's the class hierarchy for the Surface_mesh class?

tallia1

Oh sorry, misunderstood your question. Surface_mesh is an external library and not Qt, so no, it doesn't know anything about Qt at all..

goetz

Ok. That's good. It's not allowed to inherit QObject via two different paths.

So, what's the output of that little debug loop I pasted earlier?

tallia1

And this is the output of this snippet:

@
const QMetaObject *mo = model->metaObject();
qDebug() << "Hierarchy: ";
while(mo) {
qDebug() << " " << mo->className();
mo = mo->superClass();
}
@

Output:
@
Hierarchy:
SurfaceMeshModel
Model
QObject
MASSIVE FAIL.. TERMINATING
@

goetz

This is really strange. Can you boil down the code to small, yet complete test case that demonstrates the error? I don't have any clue, whats going wrong here. BTW: what operating system are you on?

tallia1

I am on OSX Lion. I isolated the problem even more. Look at the snippet below:

@
SurfaceMeshModel* model = new SurfaceMeshModel(path);

Model* retval = qobject_cast<Model*>(model);
qDebug() << "Conversion Mesh=>Model: " << (retval?"success":"failed");

SurfaceMeshModel* mesh = qobject_cast<SurfaceMeshModel*>(retval);
qDebug() << "Conversion Model=>Mesh: " << (mesh?"success":"failed");
@

And the output is ...
@
Conversion Mesh=>Model: success
Conversion Model=>Mesh: failed
@

tallia1

And now I just replaced the qobject_cast with a dynamic cast. I get a "success, success" in the test above, but a fail when it goes across the DLL boundaries (the snipped above was within the boundaries of a single compiled element).

goetz

Just for curiosity, what's the output of

@
qDebug() << "model :" << model;
qDebug() << "retval:" << retval;
qDebug() << "mesh :" << mesh;
@

tallia1

By using both qobject_cast:

@
Conversion Mesh=>Model: success
Conversion Model=>Mesh: failed
model : SurfaceMeshModel(0x1023b3fc0)
retval: SurfaceMeshModel(0x1023b3fc0)
mesh : QObject(0x0)
@

goetz

Weird. It's completely weird.

Just a another blind guess: may it be, that you happen to load two different versions of the Qt libs via the two libraries (resp. your app and library)? This may cause trouble too.

You can check this with the otool tool on the mac and some dyld debug settings:

@
export DYLD_PRINT_LIBRARIES=1
/path/to/your/Program.app/Contents/MacOS/Program 2>LOG-libraries.txt
unset DYLD_PRINT_LIBRARIES
@

Then check LOG-libraries.txt for the loaded Qt libraries:

@
grep Qt LOG-libraries.txt
@

It must not print libraries from different paths.

tallia1

I think I am approaching the esoteric here :)

These two are defined in the same header that will compile into
the same library:
@
class LOCSurfaceMeshModel : public Model, public Surface_mesh{
Q_OBJECT
Q_INTERFACES(Model)
public:
LOCSurfaceMeshModel(){}
};

class SurfaceMeshModel : public Model, public Surface_mesh{
Q_OBJECT
Q_INTERFACES(Model)
....
};
@

Then this block is executed:

@
{
LOCSurfaceMeshModel* mod = new LOCSurfaceMeshModel();
Model* retval = qobject_cast<Model*>(mod);
qDebug() << "Conversion Mesh=>Model: " << (retval?"success":"failed");
LOCSurfaceMeshModel* mesh = qobject_cast<LOCSurfaceMeshModel*>(retval);
qDebug() << "Conversion Model=>Mesh: " << (mesh?"success":"failed");
}
{
SurfaceMeshModel* mod = new SurfaceMeshModel();
Model* retval = qobject_cast<Model*>(mod);
qDebug() << "Conversion Mesh=>Model: " << (retval?"success":"failed");
SurfaceMeshModel* mesh = qobject_cast<SurfaceMeshModel*>(retval);
qDebug() << "Conversion Model=>Mesh: " << (mesh?"success":"failed");
}
@

And "OBVIOUSLY" the output is...
@
Conversion Mesh=>Model: success
Conversion Model=>Mesh: success
Conversion Mesh=>Model: success
Conversion Model=>Mesh: failed
@

Complete NO-SENSE... Sigh.. I will go by elimination now..
I will strip down the original class to the one that work..

tallia1

So by following the process above I found my error. It was this stray include lying in my runtime subsystem. (there was a time where I turned off the plugin system and did things locally)

@
#include "../lib_surfacemesh/SurfaceMeshModel.h" /// TO BE REMOVED
@

I wish I could offer more intuition on WHY it was causing the whole dynamic casting to fail.. But I seriously have no clue!

NOTE: this fixed the cast/uncast ONLY when I was trying my test code. If an object is created from a plugin, casted to the interface object and casted back to the subclass in a second plugin... the cast still fails... triple sigh...

tallia1

Let me use a small diagram to describe what is happening:
"Diagram":https://docs.google.com/drawings/d/1Jp-wpPuFTCvsC-3ovRmZXlRj93U0TfS7urxpfkLZPEc/edit

The core runtime loads the plugins1/2

Everything else is statically linked to Core Runtime

Core runtime calls plugin1 to generate an instance of SurfaceMeshModel

(note: plugin1 casts this instance to the more general Model which is the only thing runtime knows about as the diagram shows)

Core runtime calls plugin2, which receives Model* and needs to cast it back down to SurfaceMeshModel <=== This is the failure point

What I mentioned above is that now the cast/uncast of an object within a single plugin works well. But if I create an object and pass it to another plugin... that's where the casting fails...

Do you see any fault with my design?

Andrea

rcari

Your SurfaceMeshModel must be defined ONLY once in your application. If Plugin1 and Plugin2 need to know and use SurfaceMeshModel and even more pass instances of it, then you need an extra shared library that will offer it to the plugins. You must then link both your plugins to that library.
If you compile the SurfaceMeshModel in each plugin, it will work locally in that plugin but not outside of the plugin boundaries using qobject_cast.
The reason is that each plugin will have its own QMetaObject (because of the MOCed Q_OBJECT macro) for that SurfaceMeshModel class. And from a Qt standpoint two classes with different QMetaObject instances are not the same class, even if they have the exact same interface and all.
However, I am sure it would work flawlessly with a static_cast as the compiler has generated the same code and memory layout in both plugins but this is not a good practice in general.
You need an extra shared library (that your Core runtime does not need to know as far as it is concerned).