[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