Assertion failure causing immediate app exit in the debug mode when adding a connection
Posted: Sun Feb 26 2023 1:19 am
Hi there,
Thanks for the great library!
Now, the issue.
I have just got an assertion failure in the QToolBar constructor that prevents my app to start in the debug mode. A closer look shows that it is caused by broken mutex in a libguarded::SharedList<ConnectStruct>::write_handle instance in QObject::connect(). This happens when the senderListHandle is passed by value to sender.addConnection in cs_signal.h line 332, and then unlock() call when destructing the copy corrupts the mutex in the original write_handle.
I fixed the issue locally by passing the write_handle to sender.addConnection() by reference. However, the problem with copying of write_handle objects looks more general. Here is a little repro example:
Would it make sense to make the class movable-only? Or maybe use a reference counting to make sure the unlock happens only when the last copy of a write_handle object is destroyed?
Best Regards,
Yuri
Thanks for the great library!
Now, the issue.
I have just got an assertion failure in the QToolBar constructor that prevents my app to start in the debug mode. A closer look shows that it is caused by broken mutex in a libguarded::SharedList<ConnectStruct>::write_handle instance in QObject::connect(). This happens when the senderListHandle is passed by value to sender.addConnection in cs_signal.h line 332, and then unlock() call when destructing the copy corrupts the mutex in the original write_handle.
I fixed the issue locally by passing the write_handle to sender.addConnection() by reference. However, the problem with copying of write_handle objects looks more general. Here is a little repro example:
Code: Select all
libguarded::SharedList<ConnectStruct> connectList;
{
auto senderListHandle = connectList.lock_write();
*senderListHandle; // access the handle - important!
{
auto senderListHandle2 = senderListHandle; // make a local copy that is immediately destructed
}
} // <-- assertion failure in the senderListHandle destructor, as both senderListHandle and senderListHandle2 share the same mutex instance
Best Regards,
Yuri