Memory access error while scraping data from running subvi in subpanel and writing them into file

[thitchen007]

Hi all,

I'm afraid I couldn't find the bug myself so I'll tell the whole story here.

What we have here is a PC with Windows 7 64bits Home Premium OS and 4GB Memory installed and LabVIEW 2012.

We want to measure four parameters simutaneously and four corresponding independent subvi's were created. At the end we used the "Subpanel" to combine them into one main vi and tried to store the data from each subvi into a single file, accomplished in the main vi.

All the useful data are string-typed. So I wrote a subvi to "scrape" all the control referecne of the strings from the front panel of each subvi and "translate" them to corresponding string when the data are finally written into the file.

The time interval for "scraping and storing data" is set to 1 min as default.  Here the problem comes, after 2~3 days of continous running of the program, LabVIEW will crash and gives a "memory access error", sorry I now don't know exactly what error code it is but it's showing an "accessing what is not allowed to access" kind of error.

I don't know whether the error is due to the fact I set the "Find control with type.vi" and the "output array of string from array of controls.vi" to Reentrance, although I set them back to Non-reentrance, I now have no chance to test them out.

Please help and thank you for any comment!

[thitchen007]

And annother subvi.

[Norbert_B]

You should post screenshots of the error dialogs.

From what you describe, there are two possible scenarios:

a) Access Violation:

Your application tries to access a memory range which is prohibited for the application process. You OS will immediatly kill the process of your application showing a system error dialog.

b) Not enough memory:

Due to memory fragmentation and array handling (strings are U8 arrays!), you are running out of enough large memory spaces. So the overall memory consumption looks good, but if trying to build a longer string, the error occurs.

What you can do is to reduce the time until you build the string for the file. This will reduce the length of that string, effectively reducing memory fragmentation (at least its effect) for your application process.

hope this helps,
Norbert

[thitchen007]

Norbert, 

Thanks for the commmet, but I'm sorry I don't quite follow your suggestion, "reduce the time until you build the string for the file", could you explain some more on how to "reduce the time", please?

Yes I did write a long array of string into a file at once, depends on how many data are "scraped", will that cause problem?

Also, you said string are U8 arrays, my understanding is if everything is single float typed data, it would save some memory?

Thanks again for the comment!

---

@Norbert_B wrote:

You should post screenshots of the error dialogs.

From what you describe, there are two possible scenarios:

a) Access Violation:

Your application tries to access a memory range which is prohibited for the application process. You OS will immediatly kill the process of your application showing a system error dialog.

b) Not enough memory:

Due to memory fragmentation and array handling (strings are U8 arrays!), you are running out of enough large memory spaces. So the overall memory consumption looks good, but if trying to build a longer string, the error occurs.

What you can do is to reduce the time until you build the string for the file. This will reduce the length of that string, effectively reducing memory fragmentation (at least its effect) for your application process.

hope this helps,
Norbert

---

[thitchen007]

OK, finally we caught the crash, less than 50 minutes (programs runs for 10 days) after a boolean knob being switched off and then switched on, to reset a measurment, in one of the subvi's(runnning), within one of the subpanel windows. Here I attach all the crash report, please take a look and please help. We record data every 1 minute by the way.

Thanks!

[Norbert_B]

As the crash report dialog states, you are encountering an ACCESS VIOLATION. This is "common" if you embedd DLLs in your code and make mistakes by passing parameters in and out of the Call Library Function Node.

Question: Do you have custom DLLs you call?

When i say you have to reduce the time until you scrap data: i suspect that the strings are getting too long so if you scrap in a faster intervall, the chunks should be smaller. This can reduce the risk of running into memory issues.

You said, the crash occurred when the user interacted with the application. What performs the code connected to this interaction?

Norbert

[thitchen007]

Norbert, thanks again for your comment.

I'm sure it does not call any DLL inside this LabVIEW code.

When the boolean knob was turn off and then on (the "start/stop" button in the subvi code), it just simply refreshes a while loop, nothing fancy. I attached the subvi just in case.

Thank you again for your time.

---

@Norbert_B wrote:

As the crash report dialog states, you are encountering an ACCESS VIOLATION. This is "common" if you embedd DLLs in your code and make mistakes by passing parameters in and out of the Call Library Function Node.

Question: Do you have custom DLLs you call?

When i say you have to reduce the time until you scrap data: i suspect that the strings are getting too long so if you scrap in a faster intervall, the chunks should be smaller. This can reduce the risk of running into memory issues.

You said, the crash occurred when the user interacted with the application. What performs the code connected to this interaction?

Norbert

---

[Norbert_B]

Thanks for sharing your VI.

I want to give you some feedback on it in the hope that you find it usefull and see the point of it.

• Usage of stacked sequence structure: I recommend you to completly get rid of these structures as they make code less readable, scalable and flexibel for modification. Additionally, passing values from one fram to another is possible only by using variables (sequence variable/locals/globals). This is not recommended.
• Usage of variables: You use quite a lot of local variables. Variables (local and global alike) create a copy of the data if the variable is reading (writing by reference, no copy here). This can waste memory unnecessarily. Also, usage of variables can create race conditions if used in concurrent running parts of the application. Access violations might be a result of a race condition (unusual, but possible).
• Depth of diagram: When stacking structures (loops, case structures, event structure, ...), it is often the case that code is getting hidden as only one part it visible at a time. This reduces readability. I recommend you maximum "nesting" of 5-6. Your attached VI has a nesting depth of 9, which seems too high. Either replace a bunch of structures with subVIs (simply make more readable without much change) or rework the VI as some structures are not necessary. This recommendation is also part of the next feedback point.
• Style Guide: NI provides a style check list in the LV help which states recommendations on, among other things, design for the block diagram. The goal is to get a readable, scalable and maintainable code base. Your block diagram doesn't follow these guide lines, which makes it hard to read the code.

I cannot promise that if you incorporate my recommendations that the crash will go away. But with a cleaner code base, identifying and removing the source of the crash is "easier", which is in my opinion right now not really possible.

thanks,

Norbert

[thitchen007]

I'm sorry for the messy code. Thank you for all your suggestions and comments!

---

@Norbert_B wrote:

Thanks for sharing your VI.

I want to give you some feedback on it in the hope that you find it usefull and see the point of it.

• Usage of stacked sequence structure: I recommend you to completly get rid of these structures as they make code less readable, scalable and flexibel for modification. Additionally, passing values from one fram to another is possible only by using variables (sequence variable/locals/globals). This is not recommended.
• Usage of variables: You use quite a lot of local variables. Variables (local and global alike) create a copy of the data if the variable is reading (writing by reference, no copy here). This can waste memory unnecessarily. Also, usage of variables can create race conditions if used in concurrent running parts of the application. Access violations might be a result of a race condition (unusual, but possible).
• Depth of diagram: When stacking structures (loops, case structures, event structure, ...), it is often the case that code is getting hidden as only one part it visible at a time. This reduces readability. I recommend you maximum "nesting" of 5-6. Your attached VI has a nesting depth of 9, which seems too high. Either replace a bunch of structures with subVIs (simply make more readable without much change) or rework the VI as some structures are not necessary. This recommendation is also part of the next feedback point.
• Style Guide: NI provides a style check list in the LV help which states recommendations on, among other things, design for the block diagram. The goal is to get a readable, scalable and maintainable code base. Your block diagram doesn't follow these guide lines, which makes it hard to read the code.

I cannot promise that if you incorporate my recommendations that the crash will go away. But with a cleaner code base, identifying and removing the source of the crash is "easier", which is in my opinion right now not really possible.

thanks,

Norbert

---