Application stops for no apparent reason

[sfrosty]

I'm running my application on a cDAQ 9135 Linux embedded real time system. My program executes normally and will then stop execution for no apparent reason. The application generates no errors when this happens. I've monitored all exit nodes and error indicators.

I just found that there is an error report that is generated that indicates an internal error. I attached the report for reference. I hadn't seen this behavior when first developed on a windows 7 cDAQ embedded system.

The program is running 3 loops. A NI 9232 Sound Acquisition loop which inputs one channel of sound data that turns into 1/3 octaves from 20 Hz to 20 KHz. 5 NI 9230 accelerometer channels which acquire data from all 15 channels. The sound and acceleration data is then transmitted via CAN to a cDAQ 9132.

The sound and vibration toolkit functions are being utilized to perform the 1/3 octave data and accelerometer peak values generation. 

The program appears to stop at random for no known reason!

[wiebe@CARYA]

---

@sfrosty wrote:

 My program executes normally and will then stop execution for no apparent reason.

...

The program appears to stop at random for no known reason!

---

That will be hard to fix without seeing any code.

When do the crashes happen? E.g. how often? After an hour or right from the start?

There could be all sorts of things happening... Memory leaks, unclosed references, parallel execution of non-thread save VI's...

You can try to disable the loops one by one, to narrow down the problem. Or speed up\down (some of) the loops to see if the crash happens more\less frequently.

[RavensFan]

That is the longest VI name I have ever seen!

I doubt you would need to put anything into the description box for that one.

[wiebe@CARYA]

---

@RavensFan wrote:

That is the longest VI name I have ever seen!

---

For the lazy readers:

RT-Third-Octave Analysis and peak G values DAQ 200Hz 15 discreet accelerometer chnls 1 discreet sound channel and TCP .vi

That's 121 characters (including ".vi")!

[sfrosty]

It happens at random. Probably around 10 minutes is avg. Did you get a chance to review the attached error report?

[sfrosty]

Yeah! I still dread the days of 8 char DOS!

[wiebe@CARYA]

The report doesn't give much to go on, AFAIC... 99% is XML configuration of software, the other 1% simply says the VI stopped working.

If it's always around 10 min., it's not random. It might very well be a memory leak of some kind. Try speeding things down by 50%, and see if it crashes every 20 min. Or speeding things up to 200%, and see if it crashes every 5 min. If so, it's a leak (either memory or resource). If so, you need to look very carefully at growing arrays, growing queues, references that aren't closed and such.

BTW. I wouldn't be totally surprised though if the unusually long name is the problem. Almost certain it's not, but it wouldn't surprise me. It would be the most freaky bug I've ever seen...

[sfrosty]

CODE DEPICTED BELOW:

RUN ON EMBEDDED LINUX STOPS FOR NO APPARENT REASON

[aputman · Accepted solution]

Maybe the TCP queue in the top loop is the problem.  You have the dequeue disabled so data just keeps building up. 

[sfrosty]

Wow! Great Catch! I disabled and deployed. It appears the program is consistent in that it times out in about 1/2 hr. I'll see if it's still running Tue morning. If not I'll redo without TCP loop.

Renaming to short filename "Linux.vi" had no affect!

Thanks Again!!!!!