ASSERT: "isDetached()" with multithreaded QVectors

[aha_1980]

@jars121 thanks for your feedback.

sounds like a clean solution.

so please mark this topic as SOLVED now. Thanks

[SGaist]

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.

[jars121]

Thanks @SGaist I had seen mention of QReadWriteLock in my travels, but hadn't yet put any serious thought into it. I'll be sure to read further and do some testing between it and QMutex.

[jars121]

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.

[jars121]

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.

[Christian Ehrlicher]

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.

[jars121]

I figured that's what I was doing by using QReadWriteLock and corresponding QReadLockers and QWriteLockers when interacting with the shared QVectors, QLists, etc?

[jars121]

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.

[Yippiyak]

@jars121

did you ever solve this issue? I have the same problem

[Zhengyang]

Hi, @jars121
Have you found a solution? I have the same problem. And I can not solve it by adding a QMutex.

[SGaist]

@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.