LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Config to string memory leak?

Highlighted

We have an RT 2013 SP1 application running on a CFP-2220 that crashes after some days.

It writes a lot of big config files (clusters using the OpenG config file functions), and the crash report seems to indicate an issue with the NI_LVConfig.lvlib function Config to String:

From the lvlog files we can see reports like this:

 

Thread consumption suspected: 11 Try starting 1 threads
starting LabVIEW Execution System x00000002 Thread 15 , capacity: 24 at [3491480896.89672518, (15:48:16.896725292 2014:08:21)]
Thread consumption suspected: 11 Try starting 2 threads
starting LabVIEW Execution System x00000002 Thread 16 , capacity

 

then this:

<DEBUG_OUTPUT>
08/24/14 09:09:31.420 AM
DWarnInternal 0x62E90A23: Memory error 2 in DSSetHandleSize
source/MemoryManager.cpp(157) : DWarnInternal 0x62E90A23: Memory error 2 in DSSetHandleSize


</DEBUG_OUTPUT>

<DEBUG_OUTPUT>
08/24/14 09:09:32.058 AM
DWarn 0xC1EAEA9C: Internal error 2 occurred. The top-level VI "Main.vi" was stopped at unknown "" on the block diagram of "NI_LVConfig.lvlib:Config to String.vi".
source/server/RTEmbEditor.cpp(106) : DWarn 0xC1EAEA9C: Internal error 2 occurred. The top-level VI "Main.vi" was stopped at unknown "" on the block diagram of "NI_LVConfig.lvlib:Config to String.vi".


</DEBUG_OUTPUT>

 

Has this been seen by anyone else? The fact that the debugger points to that particular VI worries me as it seems unlikely to be caused by our own code then (which would be easier to fix...)

 

We'll be removing all the ini-file writes now to see if that removes the issue. If it does then we'll know that the config files are the culprit...

 

 

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 1 of 20
(1,743 Views)
Highlighted

Do you have any idea how big the configuration is when the application blows up? Could it be the config data is growing unbounded?

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 20
(1,697 Views)
Highlighted

I have no answer for you specifically, but one option you might try is using the MGI R/W anything VIs, as they have the same basic API as the OpenG VIs, so it should be easy to make the replacement and test. The two main practical differences why this might help is that the MGI VIs use the built-in variant VIs and that they don't modify the file, but rather overwrite it.

 

Potential problems with this:

 

  1. If you're relying on the specific format generated by the OpenG VIs to keep the data over time, then you will need to write code to convert the old files to the new format. Shouldn't be difficult - read using OpenG and write using MGI.
  2. The variant VIs might not work on a RT system.
  3. This might not actually help.

___________________
Try to take over the world!
0 Kudos
Message 3 of 20
(1,660 Views)
Highlighted

The config files do have a limited size. They are never read back by the system either, just written.

 

I did a test where I ran the file writing code at an accelerated rate to see if I could reproduce the issue quickly. Nothing. The leak seems to be somewhere else. We'll continue the hunt...

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 4 of 20
(1,598 Views)
Highlighted
Something to consider is that it could be a combination factors. I once had a problem where a chunk of code caused a CPU leak (It started taking more and more CPU cycles to do the same thing) but only if it included calls to the SQLite DLL and it was running in a web service. The DLL worked fine by itself. The web service worked fine by itself. But put them together and -- BOOM.

Mike.

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 5 of 20
(1,580 Views)
Highlighted

I'm down to 2 possible sources now.

One is the configuration file writing again, the other is a loop that unnecessarily called the Get Current VIs Parent Directory function (OpenG) every 30-100 milliseconds.

The OpenG function could perhaps be leaking a reference...but again, the debug output points to the config files. I'm running two parallell tests now over night to see which one is the culprit. I'm kind of hoping it is the OpenG function, not using config files would be more of a mess to clean up. 

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 6 of 20
(1,544 Views)
Highlighted

Do you use any VIs that call in a DLL (outside of NI provided VIs)? While the error report might seem to point to the config VI, it could very much be caused by a straying pointer access in a buggy or misconfugred DLL call that destroys the string that the config function tries to work on.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 7 of 20
(1,514 Views)
Highlighted

@Mads wrote:

I'm down to 2 possible sources now.

One is the configuration file writing again, the other is a loop that unnecessarily called the Get Current VIs Parent Directory function (OpenG) every 30-100 milliseconds.

The OpenG function could perhaps be leaking a reference...but again, the debug output points to the config files. I'm running two parallell tests now over night to see which one is the culprit. I'm kind of hoping it is the OpenG function, not using config files would be more of a mess to clean up. 


If you're running the Get Current VI's Parent Directory every few milliseconds, it could be that it allocates new memory for the result each time, eventually causing the resulting path to be erroneous and blow up the ini writer?

Can you grab the path outside this writing loop and use the resulting wire, or do it really need to be performed each loop? In the latter case, would it work better to use This VI's path-property and 2 strip paths?

 

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 20
(1,507 Views)

After running tests with either of the two suspects removed (or in the case of the Get Parnet Dir function - have the calls be made only when really necessary) from the application I've concluded that it is indeed the config file writes that cause the problem.

 

The config files are rather large (150 KB), and we create new ones about once a minute for 12 hours or so before we start to see the effect..(the effect is still there if the files are written slower, it just takes longer for the thread consumption warnings to pop up...).

I might be able to reduce the code down to an example that I can post here, but right now the priority is to move away from writing these large config files, and use a different file format instead. It was never an ideal file format for this use case, but it should of course not crash either...

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 9 of 20
(1,496 Views)
Highlighted

Rolf - the only DLL in the application (or .out file in this case) I'm using that is not part of the LabVIEW core is the lzlib.out file you (if I'm not mistaken) made for OpenG.

So I'm sure that's a solid piece of code Smiley Happy

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 10 of 20
(1,490 Views)