3 ms·

Came here to say that. Also note that with libstdc++ that bug is actually a use-after-free bug, which has grave security implications on top of being a regular

• Arainach 6y ago
  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" pointer.
  • 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.