Labview freezes with large memory utilization and multiple threads

[d1sturbanc3]

I'm currenting coding a really large program with multiple threads (over 5) and large memory ( > 1 gig) and buffer utlization. My program runs great for a while, but all the sudden DAQ goes away, and I'm just left with a frozen up program.

I can't stop or do anything. The only way to kill the Labview is with ctrl alt delete.

I'm hopping to get my program to run 24/7. I don't think windows is the problem, b/c as soon as I kill Labview and rerun I get everything back. What should I do to debug this? I am using Labiew 8.6.

Message Edited by d1sturbanc3 on 11-20-2008 09:43 AM

[andre.buurman@carya]

Could you by any chance post a screenshot of your code (png)?

So we can have a look at the coding style and implementation techniques used.

[d1sturbanc3]

It's quite large. What's the best way to post it? I can take screen shots, but it would require multiple screenshots.

[andre.buurman@carya]

You mentioned your division in threads. Post a screenshot of each thread. If still not possible, then your coding style need some adjustments. In that case post one thread and we'll have  a look at it to give you some pointers for improvement.

[Britoa]

without seeing your VI, we can only speculate.

you mentioned DAQ work.  Do you close every reference you open?  do you have any arrays that build and build and build?  I would guess there is some memory leak in there.

[d1sturbanc3]

Yea I have a lot of large arrays and lots of build arrays. I've lowered the sizes of my buffers and see if that helps. Will all my buffers filled, windows task manager shows me at 542,368 K and not growing. All 6 of my CPUs are at about 60% and holding.

The program is running smoothly. I've disabled my logging portion. I'll post some screen shots in a second.

[Ben]

---

Britoa wrote:

without seeing your VI, we can only speculate.

you mentioned DAQ work.  Do you close every reference you open?  do you have any arrays that build and build and build?  I would guess there is some memory leak in there.

---

Well let me jump on the speculation wagon as well.

I'm pretty close to you with my theory.but here it goes.

Over time the DAQ is falling behind because of re-allocating memory and eventually the DAQ buffer over-runs.

Maybe a producer/consumer combined with strategic pre-allocation of buffers.

But I'm just specuating!

Be

[d1sturbanc3]

Okay you guys are going regret looking at these pictures. Yes I'm using a producer, consumer, consumer, consumer x like 10 model. Lots of ffts and logging + GUI interactions

Only 3 shreenshots is not going to describe it.

[d1sturbanc3]

Here is a zip file of some screenshots. This probably covers 30% of the entire things. I'm running this on a server 6 CPU 3 TB of harddrive and 4 gig of memory.

If you are curious what this program is.. It collects data from an antennea by loging statstical information, produces a waterfall display, classify and indentify transmitter, and other jiffy things.

I'm pretty sure there are no memory leaks due to that the memory grows. If  I set my buffer to large, I do get not enough memory messages, but I'm not currently. It's just dying without any errors.

Message Edited by d1sturbanc3 on 11-20-2008 12:58 PM

Message Edited by d1sturbanc3 on 11-20-2008 01:00 PM

[andre.buurman@carya]

Your application could really use a redesign. I think that ultimately it should even be able to run on less a system than you describe

How much data do you acquire per second?

How many channels are acquired and how are they processed?

Does everything have to be processed all the time, or only when the user want to display certain analysis'.

I can see the irony of dying the block diagram with wires.