ASSERT: "isDetached()" with multithreaded QVectors
-
A bit of a development; I added a qDebug() << "Main Thread: "" << QThread::currentThread(); at the start of main.cpp, and it appears that my main class is being run twice. This is definitely not per the design, and is likely causing all sorts of issues. I'm tracing through the code at the moment and will hopefully fix this issue when I can resolve the doubling up.
-
I appear to have fixed the issue with the following changes:
- Removed the duplication error mentioned above; I was accidentally instantiating my main class twice.
- I created a new class to manage the shared QVectors separate to my main class.
- I've incorporated QMutexLockers into each function which modifies the shared QVectors.
The application has been running for around 20 minutes now without issue, so I'm hopeful that the detaching error is resolved.
-
Hi,
Just an additional tool worth mentioning: QReadWriteLock. If you are reading from several threads then you can easily access your data and as soon as there's a write going it will lock the access. It might be faster than QMutex.
-
I've marked this as 'Unsolved', as I'm afraid I'm still battling this "isDetached()" assertion.
Following SGaist's recommendation above, I've actually gone through my entire application and removed all QMutex, and replaced them with QReadWriteLocks. In short, wherever I'm reading from or writing to a shared (between QThreads) QVector, QList, etc., there's a QReadLocker or QWriteLocker (respectively) present. However, the issue remains that after a seemingly random period of time, the application will crash (in Debug mode) with the "isDetached()" assertion.
I've done some further research on this issue, and found a similar reference to this assertion here. The findings/recommendations in that thread boil down to this:
- Using the [] operator to retrieve an item at the specified index in a QVector can create a deep copy situation, which is from where a detached() scenario could arise. This is specified in the QVector Class documentation.
- Using at() to retrieve an item at the specified index in a QVector is the preferred approach if not modifying the QVector.
As it turns out, I've never used at() before, and have been completely unaware of this distinction. I'm going through my code now, with the intention of replacing all read-only QVector operator references with at().
The use of at() won't assert "isDetached()", so hopefully this solves this particular issue once and for all. I'll update the thread with my findings.
-
Well the above certainly doesn't appear to have made any difference whatsoever. I've replaced every single instance of read-only [] QVector and QList operator with .at(), but the "isDetached()" assertion is still present.
One question as I continue to review the c++ side of my application; when reading from an exposed c++ QVector in QML, is vector[i] the only/recommended way of retrieving a value from index i? The reason I ask is I might accidentally be inducing a deep copy on the QML side without knowing it. The documentation suggests that the [] operators are the correct approach, but I wanted to confirm before dismissing QML as the potential cause of this extremely frustrating issue.
-
This will definitely not fix your problems but only hide it. When using objects in multiple threads you have to sync the access with a mutex or similar as explained by SGaist and others. If you don't do it you will get into trouble sooner or later.
-
Ok so I've removed all the QReadWriteLock, QReadLocker and QWriteLocker instances, and have gone back to QMutex with QMutexLockers. I've been somewhat more diligent this time around, and in combination with the change from [] operators to .at() the application seems to be running smoothly.
I've got further testing to do before I'm completely comfortable, so I'll leave the thread open for the time being.
-
-
@Zhengyang hi and welcome to devnet, it's described in the last post of @jars121.
If QMutex does not solve your issue, you are likely misusing it.
