Dequeue element freezes (timeout = 0)

[blazkelbl]

Hi!

I'm having trouble understanding why the code in the picture freezes. I get the queue reference (previously stored as a class member) and attempt to dequeue the element with a timeout value = 0. My program freezes (but only after a day or so). Using the highlight execution the cause appears to be dequeue element vi. 

Any suggestion ise very welcome. 

Blaz

[pincpanter]

Does the GET CMD QUEUE open a new queue reference or return an internally stored reference? In the first case, you should close the reference afterwards.

[blazkelbl]

It returns an internally stored reference. 

[pincpanter]

I'm sorry I don't have an explanation for this. A call with 0 timeout can't freeze, unless the LV runtime is misbehaving.

This means that some weird thing happened somewhere, either in the runtime (corrupted installation?) or in the program (dangerous dll calls? memory leaks?).

[paul.r]

Strange.. Where else are you using that queue in your application? This only occurs after the application has been running for a day straight?

What is in the queue messages? Are you doing anything with DVRs in your application? 

[Norbert_B]

I assume that the whole application is frozen. And i assume that this is an actor based application. Correct?

The information that the dequeue element is frozen is incorrect. I guess that the UI thread is hanging. Therefore start investigation what part of code is running in the UI thread.

Also check if the application creates CPU load once it is frozen. There are two typical options for that: 0% or 100% ("really frozen" vs. "completely hogged"). Also verify that there are no external code segments which could block event based.

[blazkelbl]

Thank you for your answers.

@paul.ross:

I'm using this queue in this thread, but to my knowledge, there can't be any parallel accesses to it. 

The freeze happens in a day or so - there are 10 threads like it running and slowly, one-by-one they hang. the queue contains a cluster of values (no references). 

The thread uses the DVR to store its members but nothing is done with the DVR after the creation (and deletion at the end). There is access to the members of the object in other threads, but only reading. 

@Norbert_B:

The application thread is frozen, other same threads run normally (though from past experience they'll run into the same problem). The application is not actor based, it's a queue (though not the queue in the screenshot) based messaging OOP application and there is not UI thread connected to the frozen thread. The UI is responsive, though it the application will hang when exiting (due to inability to close the frozen thread). 

By saying that the information that the dequeue element is frozen is incorrect, do you imply that to be correct the dequeue VI should have the green arrow over it?

I can't check the CPU usage in total because the other threads are running, but it's not 100%. 

[Norbert_B]

Do you have any force destroy on that queue somewhere in the code?

[blazkelbl]

No force destroy.

I'll try to obtain the queue in a separate VI by its name when the freeze occurs, but I have to restart the application because the queue data type def is in the private scope and I can't use it outside of the class - hopefully that will tell something about the state of the queue. 

[blazkelbl]

Just to give some update: I haven't found a reason for the problem, however, setting the timeout to 1 ms solves the issue.