11-29-2020 02:19 AM
@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.
11-29-2020 10:27 AM
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.
12-01-2020 02:47 AM
@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.
12-01-2020 02:54 AM
@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.
12-01-2020 03:17 AM
@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.
12-01-2020 03:58 AM
@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.
12-01-2020 07:55 AM
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?
12-01-2020 09:31 AM
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).
12-01-2020 09:52 AM
@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.
12-01-2020 10:00 AM
@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!