3 ms·

It's not use-after-free - the object is in the process of being destroyed, the memory hasn't been released yet. This just has to do with the value of the "this

• armada651 6y ago
  The question is, why would KDE need the pointer value after the referenced object is destroyed? That implies a use-after-free.
  • varajelle 6y ago
    Big applications can be complicated and have some complex states. A destructor calls a function that calls a function that checks if an object exist. By chance with libstdc++, the half destroyed object was marked as "non existent", but not with libc++. Destructor usually call function to unregister themselves from some other places, or free other owned ressources.
  • ttt0 6y ago
    They don't. If I understand it correctly, destroying the object triggers the QEvent::Destroy event, which then goes through the event handler on the parent object that might access that pointer. On libc++ that pointer is set to null before calling the destructor and triggering the event, so it's null pointer dereference. The object is accessed only through the unique_ptr, so unless multithreading is going on, I don't think there is a way to have use-after-free. You might be potentially accessing garbage, but it's not use-after-free. Aside, using a pointer to an object that is destroyed is not always use-after-free. Accessing the value might happen during the destruction, which is the case here or the object can be destroyed, but the memory is not released. "Placement new" and stuff.
• beached_whale 6y ago
  I think they need to do something like auto tmp = _d.release; prior to the rest of the code. then the lifetime is extended to the current scope and after the event thing is done.