LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Corrupted INI file


@JB wrote:
I suppose that this is the starting point for rare cases (2-3/year, about 150 LV applications run on our assembly lines) with the disappearance of the useful data.

I have also had a few very rare cases of customers saying "the system doesn't work" and then looking and seeing that an INI file was reset to its default values.

 

These aren't cases I supported directly, so I don't remember the details and I don't have any forensic data for analysis, but because of the rarity, it was generally just handled by just reconfiguring or restoring from backups. I believe it did strike repeatedly at the same customers or at customers with similar software, so I suppose it is possible it's something wrong in our code in those cases, like a race condition.


___________________
Try to take over the world!
Message 11 of 25
(249 Views)

Since it has not been mentioned yet I shook my 8-Ball!  

 

Hold it!  The configuration API was revamped between 8.6 and 2009!  Some of the really old code even have Open G dependencies.   

 

How old is the source?  Is it mixing and matching configuration API subvis across the 8.6 - 2009 boundary?( always bad!)  Are there any other forensics < the missing NUL between sections is something that only AQ can answer> 

 

NUL is alt&0000 easy to  type if you are not on a phone.


"Should be" isn't "Is" -Jay
Message 12 of 25
(239 Views)

@drjdpowell  a écrit :

You could just copy either the open or close VIs and modify it to drop NULs.  Then use this new version in your apps.  Assuming the issue, whatever it is, is just adding NULs, rather than messing up something else.


Thank you.

 

We are thinking about workarounds and your suggestion could be a solution.

Right now, we're trying to intercept as many files as possible to make sure the problem is always the same. In our collection, there is currently a file with spaces and not NUL.

0 Kudos
Message 13 of 25
(203 Views)

@drjdpowell  a écrit :

Do any of your multiple apps share common config files?  Possible loss of data can happen due to read-write race conditions.  If I were asked how to improve that NI library, fixing that hole would be my first suggestion.


An interesting idea but none of the corrupted files are shared.

0 Kudos
Message 14 of 25
(201 Views)

@tst  a écrit :

@JB wrote:
I suppose that this is the starting point for rare cases (2-3/year, about 150 LV applications run on our assembly lines) with the disappearance of the useful data.

<snip>

but because of the rarity, it was generally just handled by just reconfiguring or restoring from backups

<snip>


This is what we are doing at the moment. But we have to fix this problem because although it is very rare, it can stop a production for several hours if it arrives at night or on weekends when support is not present.

0 Kudos
Message 15 of 25
(194 Views)

@JÞB  a écrit :

Since it has not been mentioned yet I shook my 8-Ball!  

 

Hold it!  The configuration API was revamped between 8.6 and 2009!  Some of the really old code even have Open G dependencies.   

 

How old is the source?  Is it mixing and matching configuration API subvis across the 8.6 - 2009 boundary?( always bad!)  Are there any other forensics < the missing NUL between sections is something that only AQ can answer> 

 

NUL is alt&0000 easy to  type if you are not on a phone.


Thank you.

 

Some applications may be affected but by far not all. Some intercepted files come from very recent applications. If an application needs to be refreshed, replacing those VIs (I don't like those with a big red cross in the icon 😂) is part of the actions.

 

I know the alt+ code of the NUL character but a modification by an operator is unlikely. These configuration files are "hidden" in a subdirectory and operators never have to modify them manually. In addition, while the cases are rare, they have appeared in too many applications, spread throughout the company, to suspect an operator.

 

 

For the moment, the intercepted cases are too few for a definitive conclusion but the number of NUL (or spaces) seems in relation to that of the data of the file.

0 Kudos
Message 16 of 25
(191 Views)

Are some of the key/value pairs created programmatically?  Maybe some weird chain of events leads to some error condition that leads to the creation of a bad key name and/or value?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 17 of 25
(171 Views)

I have only a vague memory of this happening once, but I'm not sure.

I'm sure instead that since version 7 until a couple of years ago, sometimes (very seldom) happened that the ini file was completely wiped out.

This happened only for applications writing into the file. I admit that the design was wrong, since writing was done item-per-item by means of dedicated vis, one for integers, one for strings, one for floating point values. All those vis opened the ini file, wrote and close. Obviously, this seems to call for race conditions. Still, I can't figure out why the file disappears, instead of being corrupted.

Finally, I serialized all writings to the file and the problem disappeared (so far: it was very erratic).

Paolo
-------------------
LV 7.1, 2011, 2017, 2019
0 Kudos
Message 18 of 25
(159 Views)

@billko  a écrit :

Are some of the key/value pairs created programmatically?  Maybe some weird chain of events leads to some error condition that leads to the creation of a bad key name and/or value?


Keys are obviously generated if they do not exist. But this is the case only when running the application for the very first time. Thereafter, only the values can change.

 

As the example from my first post shows, keys and data remain intact. At least initially.

 

I've wondered if an error while updating values, between opening the file and closing it, could cause these unexpected characters.

0 Kudos
Message 19 of 25
(155 Views)

@pincpanter  a écrit :

I have only a vague memory of this happening once, but I'm not sure.

I'm sure instead that since version 7 until a couple of years ago, sometimes (very seldom) happened that the ini file was completely wiped out.

This happened only for applications writing into the file. I admit that the design was wrong, since writing was done item-per-item by means of dedicated vis, one for integers, one for strings, one for floating point values. All those vis opened the ini file, wrote and close. Obviously, this seems to call for race conditions. Still, I can't figure out why the file disappears, instead of being corrupted.

Finally, I serialized all writings to the file and the problem disappeared (so far: it was very erratic).


Thank you for this information even if we do not update our files in this way.

As said before, if someone happens to find an INI file with the same corruption as what we are seeing, I am very interested!

0 Kudos
Message 20 of 25
(146 Views)