[Development] Not delivering signals to slots in class sub-objects already destroyed
Thiago Macieira
thiago.macieira at intel.com
Wed Sep 3 23:17:25 CEST 2025
On Wednesday, 3 September 2025 00:24:46 Pacific Daylight Time Fabian Kosmale
via Development wrote:
> So I would expect that moc can track the depth[1], and we can store
> it directly inside the meta-object, making the check O(1) for code compiled
> against a new enough code.
That's a good idea, but it could fail if someone splits an intermediary class
in a shared library into two, but the next library doesn't recompile it.
libQtCore.so: QObject
→ libFoo.so: FooObject
→ app: AppObject
AppObject depth = 2
later
libQtCore.so: QObject
→ libFoo.so: BarObject
→ libFoo.so: FooObject
→ app: AppObject
The depth recorded in the meta object is still 2, but it is in fact 3 (it
could be the reverse too). This means that we'd record in the Connection that
we need a depth of 2, so the connection would be delivered even after
AppObject got destroyed.
We'd need to do a check at connection time to see if the number is accurate
and, if not, keep the hierarchy iteration.
BTW, do note that something equivalent to that is there for the string
connections too that go through the qt_static_metacall:
} else if (c->callFunction && c->method_offset <= receiver-
>metaObject()->methodOffset()) {
the methodOffset() call iterates through the parents and adds the method count.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel Platform Engineering Group
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20250903/70692cc6/attachment.bin>
More information about the Development
mailing list