dequeue error reading INI file

[Ben]

---

@crossrulz wrote:

---

@Ben wrote:

---

I think that is what I had guessed. I will et you chase it down in the code but I suspect one loop is closing the file before the second has completed the read. Call your tow loops A and B.

A opens the file and the queue gets created

B Opens the file and the queues already exists

A Reads from the file.

A closes the file

B attempts the read.... Error because the queue was destroyed.

---

Nope.  The queues are unnamed inside of the configuration file library.  So two separate calls to the Open Config Data will not collide.

My main guess is there is a miswire so that the proper reference is not going to a Read Key VI, which will result in an invalid reference to the queue.  Again, we need to see code.

---

Yes, now that I actually went back and looked at it...

Your theory about the miswire seems valid.

Ben

[nyc_(is_out_of_here)]

---

@Ben wrote:

---

@crossrulz wrote:

---

@Ben wrote:

---

I think that is what I had guessed. I will et you chase it down in the code but I suspect one loop is closing the file before the second has completed the read. Call your tow loops A and B.

A opens the file and the queue gets created

B Opens the file and the queues already exists

A Reads from the file.

A closes the file

B attempts the read.... Error because the queue was destroyed.

---

Nope.  The queues are unnamed inside of the configuration file library.  So two separate calls to the Open Config Data will not collide.

My main guess is there is a miswire so that the proper reference is not going to a Read Key VI, which will result in an invalid reference to the queue.  Again, we need to see code.

---

Yes, now that I actually went back and looked at it...

Your theory about the miswire seems valid.

Ben

---

There is no miswire.

The VI is one self-contained unit as I mentioned before.

Opens,Reads,Closes.

If I run the VI standalone, it works.

It's a race condition. I have decided to have just one VI read the INI file once. That's it.

The other option is to make the VI reentrant.

.

[nyc_(is_out_of_here)]

forgot to attach VI

.

[paul.r]

---

@nyc_(is_out_of_here)

---

There is no miswire.

The VI is one self-contained unit as I mentioned before.

Opens,Reads,Closes.

If I run the VI standalone, it works.

It's a race condition. I have decided to have just one VI read the INI file once. That's it.

The other option is to make the VI reentrant.

.

---

I dont believe this. The VI you attached is not the VI that caused the error. 

[pincpanter]

Your VI is not reentrant, so only one instance at a time can be executed.

This means that no access conflict is possible. Unless there are other vi's accessing to the file.

Paul is right, the original vi is READ_VALUE.vi. Why you did not attach that one?

[Ben]

---

@pincpanter wrote:

Your VI is not reentrant, so only one instance at a time can be executed.

This means that no access conflict is possible. Unless there are other vi's accessing to the file.

Paul is right, the original vi is READ_VALUE.vi. Why you did not attach that one?

---

I think that VI was the solution and not the problem. While I was not involved with the issue about 4 years ago the LVOOP classes I had developed for file I/O was modified by another developer ( now working elsewhere) when he discovered an issue with multiple threads accessing a cfg file and the file getting closed by parallel threads. I just took the updated objects and ran with them from there.

While that does not fully explain what the problems that NYC ran into were, it does seem like an issue that I can believe but do not have the time to investigate.

For what it is worth...

Ben

[paul.r]

I still don't believe it. 

The entire file access occurs in a single, non reentrant VI within the open. The data is stored in the queue from then on out until the close config file is called. 

You can very easily test this parallel access- open a reference to a config file, then open another. Read from the first reference, close it, then attempt to read from the second. No errors occur, because they are two completely separate queue references - the fact that it is the same config file is completely irrelevant. So either NYC has discovered a massive bug with the LabVIEW Queues and Ini file libraries that are used without issue by thousands of users for years, or he is wrong about what he is doing. 

[pincpanter]

  ha scritto:

I still don't believe it. 

The entire file access occurs in a single, non reentrant VI within the open. The data is stored in the queue from then on out until the close config file is called. 

You can very easily test this parallel access- open a reference to a config file, then open another. Read from the first reference, close it, then attempt to read from the second. No errors occur, because they are two completely separate queue references - the fact that it is the same config file is completely irrelevant. So either NYC has discovered a massive bug with the LabVIEW Queues and Ini file libraries that are used without issue by thousands of users for years, or he is wrong about what he is doing. 

---

I would not really say "without issue". I had a problem many years ago (LabVIEW 7) in a program being developed that at start-up randomly cleared the content of its ini file about 80% of times, then running with default settings.

The file was only read and never written in the application, but I overlooked the "write if necessary" flags, leaving them to the default (true).

The problem disappeared setting all flags to false.

I have another application around (>20 customers) in LabVIEW 2011 that actually writes some values to its ini file; from time to time (very seldom) the ini file is cleared up and must be restored. I'm not sure but it seems to be a problem similar to the above case, only much less likely.

And I'm not the only one, see for example this and this.

[Ben]

---

@pincpanter wrote:

... 

---

I would not really say "without issue". I had a problem many years ago (LabVIEW 7) in a program being developed that at start-up randomly cleared the content of its ini file about 80% of times, then running with default settings.

The file was only read and never written in the application, but I overlooked the "write if necessary" flags, leaving them to the default (true).

The problem disappeared setting all flags to false.

I have another application around (>20 customers) in LabVIEW 2011 that actually writes some values to its ini file; from time to time (very seldom) the ini file is cleared up and must be restored. I'm not sure but it seems to be a problem similar to the above case, only much less likely.

And I'm not the only one, see for example this and this.

---

I can report that LV 7.0 had a bug with file references getting scrambled if you closed and opened file quickly.

In the case were I found the bug, I was writing datalog files and closing them after a day and then opening new ones immediately afterwards to keep a running 24X7 log.

On occasion, the references would get mixed up and files that started as one datalog type were being appended with other datalog file types. That in the end resulted in LV crashing when trying to re-open those files. It was no easy task unwinding those files!

I have also heard of issues with config files being corrupted during brow-outs on some cRIOs. I had a customer with two cRIOs that both just went crazy and could not be fixed using the normal tools like MAX etc. I sent them back for repair and after they were re-blasted with new firmware "No trouble found".

All of those stories do not help much I realize aside from the fact that some bugs have been fixed and there may be others. As far as config files go, if I wire something to a config file, I make sure the data is written to disk by closing the file (The old config files had a function not on the palette that would let us write to file but that was dropped when the config files were re-written). I reopen afterwards if I need to do more reads fro the file.

[paul.r]

Bugs that were present in a version of LabVIEW that is now almost 15 years old aren't really relevant to what we are discussing. NYC is using LabVIEW version 2015. To clarify my earlier statement - the ini files in their current form work without issue. 

If nyc is actually doing what he is describing, recreating the problem should be easy. When nyc posts code that demonstrates the problem, I'll put on a dunce cap and admit I was wrong. Until then, I still don't believe it. 😃