LV2012 Out of Memory Bug when Clearing Compiled Object Cache

[User002]

---

@Norbert_B wrote:

Roger,

your attachments somehow irritate me.

Missing_BD.zip seems to have the very same content as the original Execution.zip. All class VIs have their BD removed and do contain code (even if option seperate source code is checked, but the option itself is greyed out).

Execution_Fixed.zip does contain all BDs for all VIs, but the issue with the broken error is not reproducable on my machine. I checked some of the subvis, but it seems all have the option to seperate the source code set.

EDIT: Ok, following you initial description i can reproduce the issue.

EDIT 2: I can reproduce the issue only if i opened one of the Load Core.vis before purging the cache. Please confirm.

Norbert

---

For me, I got to run the "Performance.vi", stop it, leave the VI it open, clear the cache, close the VI and reopen it <- have you tried that?

Maybe it manifests itself differently on various computers/setups?

Br,

/Roger

[Norbert_B]

Roger,

just for clarification:

I am using your _Fixed example all the time (the other two wont work). The main VI is called "Benchmark.vi". Loading of VIs is done by opening the Benchmark.vi from the project, other VIs are loaded via the callers BD (double click the instance) if not stated otherwise.

Initialize:

With nothing open in LV, clear cache.

1. Open Project
2. Load Benchmark.vi.
3. Clear cache (nothing done) tells me it would clear 484kB of cached files. Do so.
4. Close Benchmark.vi
5. Reopen Benchmark.vi. Run arrow is "normal".
6. Clear cache (nothing done)  tells me it would clear 55kB of cached files. Do so.
7. Close Benchmark.vi.
8. Reopen Benchmark.vi. Run arrow is "normal". Rinse and repeat steps 6-8 as often as you like, i found no change.
9. Reopen Benchmark.vi. Force compile it (Ctrl+Mouse click on run arrow).
10.  Clear cache tells me it would clear 281kB of cached files. Do so. Possibly, the size could be 55kB as well. Might depend if you canceled a clearing before...
11.  Close Benchmark. vi
12.  Reopen Benchmark.vi. Run arrow is "normal". Repeat stept in range 6-12, there shouldn't be any change.
13.  With Benchmark.vi open, change to the BD. Open any of the Create functions. I saw that those have their BD removed.
14.  Clear cache. Does not matter if the Create vi you opened at step 13 is still open or not. Cache size should still be 55kB or 281kB.
15.  Close Benchmark.vi (and Create if still open).
16.  Reopen Benchmark.vi. Run arrow is "normal".
17.  Open BD and open any of Load Core.vi.
18.  Clear cache. Does not matter if the Create vi you opened at step 17 is still open or not. Cache size should still be 55kB or 281kB.
19.  Close Benchmark.vi.
20.  Reopen Benchmark.vi. Run arrow is broken and clicking on it reveals the "out of memory" error.

So it seems that the error is altogether connected to Load Core.vi and its dependencies.

Therefore, i made an additional test:

1. Initialize (clear cache from LV start screen).
2. Repeat steps 1-5 from the first test
3. Open the BD of a Load Core.vi. Open the three subvis (lock, unlock and UnRefGetEndExecution) and force compile them.
4. Close the subvis and force compile Load Core.vi
5. Force compile Benchmark.vi
6. Close all VIs, leaving the project open.
7. Reopen Benchmark.vi. Run arrow is "normal"!

So it definetly seems that there is a mess up in the compile hierarchy within Load Core.vi. So the question is: What would be a reason for this?

Norbert

EDIT: Closing LV with an "executable" version of Benchmark.vi loaded as last item, there comes a dialog telling about internal warnings and if i want to send them to NI. So it is no error send dialog. Still, it is remarkable that LV behaves so....

[User002]

---

@Norbert_B wrote:

Roger,

just for clarification:

I am using your _Fixed example all the time (the other two wont work). The main VI is called "Benchmark.vi". Loading of VIs is done by opening the Benchmark.vi from the project, other VIs are loaded via the callers BD (double click the instance) if not stated otherwise.

Initialize:

With nothing open in LV, clear cache.

1. Open Project
2. Load Benchmark.vi.
3. Clear cache (nothing done) tells me it would clear 484kB of cached files. Do so.
4. Close Benchmark.vi
5. Reopen Benchmark.vi. Run arrow is "normal".
6. Clear cache (nothing done)  tells me it would clear 55kB of cached files. Do so.
7. Close Benchmark.vi.
8. Reopen Benchmark.vi. Run arrow is "normal". Rinse and repeat steps 6-8 as often as you like, i found no change.
9. Reopen Benchmark.vi. Force compile it (Ctrl+Mouse click on run arrow).
10.  Clear cache tells me it would clear 281kB of cached files. Do so. Possibly, the size could be 55kB as well. Might depend if you canceled a clearing before...
11.  Close Benchmark. vi
12.  Reopen Benchmark.vi. Run arrow is "normal". Repeat stept in range 6-12, there shouldn't be any change.
13.  With Benchmark.vi open, change to the BD. Open any of the Create functions. I saw that those have their BD removed.
14.  Clear cache. Does not matter if the Create vi you opened at step 13 is still open or not. Cache size should still be 55kB or 281kB.
15.  Close Benchmark.vi (and Create if still open).
16.  Reopen Benchmark.vi. Run arrow is "normal".
17.  Open BD and open any of Load Core.vi.
18.  Clear cache. Does not matter if the Create vi you opened at step 17 is still open or not. Cache size should still be 55kB or 281kB.
19.  Close Benchmark.vi.
20.  Reopen Benchmark.vi. Run arrow is broken and clicking on it reveals the "out of memory" error.

So it seems that the error is altogether connected to Load Core.vi and its dependencies.

Therefore, i made an additional test:

1. Initialize (clear cache from LV start screen).
2. Repeat steps 1-5 from the first test
3. Open the BD of a Load Core.vi. Open the three subvis (lock, unlock and UnRefGetEndExecution) and force compile them.
4. Close the subvis and force compile Load Core.vi
5. Force compile Benchmark.vi
6. Close all VIs, leaving the project open.
7. Reopen Benchmark.vi. Run arrow is "normal"!

So it definetly seems that there is a mess up in the compile hierarchy within Load Core.vi. So the question is: What would be a reason for this?

Norbert

EDIT: Closing LV with an "executable" version of Benchmark.vi loaded as last item, there comes a dialog telling about internal warnings and if i want to send them to NI. So it is no error send dialog. Still, it is remarkable that LV behaves so....

---

Damn, that was a detailed "steps to reproduce".

There lives a menacing tester within you Norbert! 

What I can speculate of could cause some problems is the inlined lock.vi/unlock.vi inside the inlined Load Core.vi. Also the inline functionality is fairly recent, perhaps still not having the same mileage as in the other LV primitives?

Seem to be a possible cause after testing a little. I disabled the inline from Load Core.vi.

And now I don't get any "internal warning" dialogs after I end LV and fiddling with the clear compiled cache back and forth.

Give it a shot on your end? 

Br,

/Roger

EDIT: I am on my 64bit workstation now.

[Norbert_B]

---

@Norbert_B wrote:

[..]

So it seems that the error is altogether connected to Load Core.vi and its dependencies.

Therefore, i made an additional test:

1. Initialize (clear cache from LV start screen).
2. Repeat steps 1-5 from the first test
3. Open the BD of a Load Core.vi. Open the three subvis (lock, unlock and UnRefGetEndExecution) and force compile them.
4. Close the subvis and force compile Load Core.vi
5. Force compile Benchmark.vi
6. Clear cache.
7. Close all VIs, leaving the project open.
8. Reopen Benchmark.vi. Run arrow is "normal"!

[..] 

---

Forgot step 6. Just for completeness..

Will try to find additional information if i have more time (currently doing something else... )

Norbert

[Norbert_B]

Roger,

i passed the information on to R&D and CAR #374133 was filed. Currently, we have no further information about the source other than the experience that setting "Seperate Source Code" together with "Inline" is causing the issue (your finding, well done 😉 ).

As a workaround, i suggest to NOT use "Inline" even if it does affect performance a little bit in a negative way (depending on the content of the subvi).

hope this helps,

Norbert

[User002 · Accepted solution]

---

@Norbert_B wrote:

Roger,

i passed the information on to R&D and CAR #374133 was filed. Currently, we have no further information about the source other than the experience that setting "Seperate Source Code" together with "Inline" is causing the issue (your finding, well done 😉 ).

As a workaround, i suggest to NOT use "Inline" even if it does affect performance a little bit in a negative way (depending on the content of the subvi).

hope this helps,

Norbert

---

Thanks Norbert! Awesome teamwork here! 

Br,

/Roger