QString bad alloc
-
the object only lives in the thread, and I use TOP to see the memory status but it is always at 2/3% always low
-
do you know if it is a bug fixed in the following qt?
It's very unlikely that this is a bug in QString itself (or malloc). A typical cause of such errors is heap corruption - that is, in some other code you're accessing memory outside of the allocated bounds, which corrupts the metadata that malloc uses to manage memory.
These types of issues can be really hard to track down. Anyhow, a tool like valgrind/memcheck can be of help.
Good luck!
-
@Massimiliano75 , Can you please show or state the scopes of where your variables are defined?
For example where is QStringList list; defined and what is its lifetime ?
-
@Massimiliano75 , Can you please show or state the scopes of where your variables are defined?
For example where is QStringList list; defined and what is its lifetime ?
@SPlatten
for example but line changes
-
@Massimiliano75 , looking at the outer for loop, this will iterate as fast as it can on the hardware it is running on, there are no delays between iterates, each iterates starts by clearing the list then rebuilding it, the list isn't visible to anything else outside of the thread so by do you use a mutex to lock and unlock around appending data to what is an internal list and then only on the second append, I can't see that the mutex is required at all.
-
@Massimiliano75 , looking at the outer for loop, this will iterate as fast as it can on the hardware it is running on, there are no delays between iterates, each iterates starts by clearing the list then rebuilding it, the list isn't visible to anything else outside of the thread so by do you use a mutex to lock and unlock around appending data to what is an internal list and then only on the second append, I can't see that the mutex is required at all.
-
@SPlatten
I think the mutex lock is to protect something in the parameters OP is passing tolistBarInfo.append()on that particular line, though not sure what.... -
@JonB , then wouldn't it be better to put the mutex locking and unlocking in the access method used?
@SPlatten
Well quite possibly! But we don't know why whatever needs locking, and what it needs locking against. Maybe it only needs locking when called from here? Maybe the thing(s) which need locking do not have access to themutexModuleDatavariable which we do here?Certainly it might be clearer/safer to assign such things to local variables in a locked region and then pass those as parameters to whatever is being called, like e.g.:
mutexModuleData.lock(); auto something = sharedVariable; auto something2 = sharedFunction(); listBarInfo.append(something, something2); mutexModuleData.unlock();But this all assumes that is why the OP locked this particular statement and not others. For which we do not have confirmation.
-
@SPlatten
Well quite possibly! But we don't know why whatever needs locking, and what it needs locking against. Maybe it only needs locking when called from here? Maybe the thing(s) which need locking do not have access to themutexModuleDatavariable which we do here?Certainly it might be clearer/safer to assign such things to local variables in a locked region and then pass those as parameters to whatever is being called, like e.g.:
mutexModuleData.lock(); auto something = sharedVariable; auto something2 = sharedFunction(); listBarInfo.append(something, something2); mutexModuleData.unlock();But this all assumes that is why the OP locked this particular statement and not others. For which we do not have confirmation.
