LabVIEW User Interface --> Memory allocation processing User Messages

[Oli_Wachno]

Hi there,

I've been stress-testing a LabVIEW based UI today firing UI messages at different speeds from TS to the UI.

Depending on the speed, the UI stalls with a out of memory error.

Restarting everything and checking with the task manager, I can observe that LabVIEW.exe is constantly increasing memory usage.

The Profiler, does not show VIs with increasing memory usage. The DETT shows lots of resizing, but no errors, no leaks, nothing obviously suspicious...

To track down the cause, I stripped down UI to simply receiving messages:

- Receive the message with the callback VI and post the message via dynamic event to the main event loop of the UI

- The event loop just "ignores" the message, it executes the dynamic event, but in there, it just does nothing

The behavior is still existing. I find one thing still suspicious looking at the DETT log. There is an ActiveX MousDown listed.

Don't know if its for real or where it is coming from... I'm using not the ActiveX controls from TS. So if it is for real, this event is not handled

Happy for any advice

Cheers

Oli

[Oli_Wachno]

Additional information / questions:

• does TestStand Memory consumption show in the Task Manager under LabVIEW.exe?
• if so.... when commiting to version control last night, I realized that the message-firing sequence had result logging enabled. But never actually wrote a report to clear the result container... so this could be the reason....

I won't have the chance to check it out before tonight. Will let you know if it worked out.

[Oli_Wachno]

Suspicion confirmed:

• TestStand has been allocating memory due to not disabling result collection and not processing the Result Object
• Memory allocation by TestStand shows up in the TaskManager under LabVIEW.exe

Memory allocation by TestStand can not be observed by DETT or the profiler (can anyone confirm this?)

Stress testing overnight has been sucessfull: 18 sockets in parallel firing 8 messages each every 0.5s stable over >10 hours