QString bad alloc

Massimiliano75

I use Qt 5.15.2, linux,

every five seconds I create a string and append other strings to it from inside a thread for example:

QStringList list;
list.append(QString("1"))

every 3/4 hours, very variable time crashes.

stack

__GI__libc_malloc
QArrayData :: allocate (unsigned long, unsigned long, ...)
QString :: QString (QChar const *, int)

has it happened to someone?

do you know if it is a bug fixed in the following qt?

jsulm

@Massimiliano75 said in QString bad alloc:

every five seconds I create a string

Do you mean string list (QStringList)?
Maybe you're getting out of memory?

JonB

@jsulm said in QString bad alloc:

Maybe you're getting out of memory?

I calculate this incredibly roughly at, say, 100K after 4 hours. If the OP is running out of memory on this they have big problems!

Christian Ehrlicher

@Massimiliano75 said in QString bad alloc:

other strings to it from inside a thread for example:

You must not access an object from two different threads without proper locking mechanisms

Massimiliano75

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

kkoehne

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!

SPlatten

This post is deleted!

SPlatten

@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

@SPlatten
for example but line changes

SPlatten

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

JonB

@SPlatten
I think the mutex lock is to protect something in the parameters OP is passing to listBarInfo.append() on that particular line, though not sure what....

SPlatten

@JonB , then wouldn't it be better to put the mutex locking and unlocking in the access method used?

JonB

@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 the mutexModuleData variable 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

@JonB , @Massimiliano75 , I would suggest that moving the mutex management into the access method its the logical and best place for it.