LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Text file has chunk of data from 65K bytes earlier appended to end when closed

I've just become aware of a very strange behavior with a data logging VI that has been in use in several pieces of DAQ software we use in-house for years.  The vi creates an empty file, appends lines of text (consisting of a time stamp and tab-delimited floating point numbers) to the end of it at regular intervals, flushes the buffer to disk every minute, and closes the file at the end of the day or if the software shuts down.

 

It's relatively straightforward code, and has worked for years without issue.  It was originally written in LabVIEW 6, but has been updated a bit along the line as LabVIEW advanced.

 

However, we just discovered a problem with a system using the subvi recompiled for LabVIEW 2012 on a Win7-based system.  It appears, on file close, to be grabbing a chunk of data (of random length in the 1-8K range) from around 65000 bytes before the end of the file, and appending that data to the end of the file.  It does not do this every time the file closes--it's very intermittent.  The length of the files is not consistent, the amount of data before the flakeout is not consistent, the amount of data copied to the end is not consistent.

 

The only constant is the distance between what should be the end of the file and where it started copying the data from--I have seen 65082, 65094, and 65100 bytes exactly, no other values, across a number of files.

 

The number is too precise to be a coincidence, but I'm baffled as to what could be doing it--the software *never* reads data from the file or buffers any old data, so there's no way I can understand that it could even be coming up with the old data to write to the file.  The file pointer is also explicitly set to the end of the file on every write, and the data is being duplicated anyway, so it's not acting as if the pointer is getting set to the wrong place.

 

The only changes I'm aware of in the software between a version that was behaving normally (at least that the people processing the data noticed) and not was a recompile for LabVIEW 2012, and changing the platform from XP to 7.

 

Does anyone have a suggestion of what I might look at as a possible source of this behavior?  I'm really baffled.

0 Kudos
Message 1 of 2
(2,173 Views)

My guess:  The code has a race condition that did not come to your attention when using a previous version of LabVIEW.  That race condition seems to be located somewhere where the file is closed.  Can you provide more details about that part of the code?

0 Kudos
Message 2 of 2
(2,139 Views)