File locked?

[dseel]

Hi:

We seem to have found a strange combination of conditions which causes a file to be locked (unable to be deleted/renamed).

Here is the scenario:
* modified full featured teststand 4.0.1 CVI user interface with a timer callback called every second (using CVI 8.0.1)
--> callback calls LaunchExecutable with command.com (just running 'dir' in the example, but normally I'm piping output from another exe to a file)
--> callback creates and writes to a file using fopen/fputs/fclose
* run a sequence (WriteAFile.seq) which calls a DLL which continuously writes to a different file (c:\temp\writeafile.txt) using the CVI WriteFile function
* if the DLL is called several times (1000+), after completion writeafile.txt appears locked - it can not be deleted until the user interface is shutdown

All relevant files are attached. Unzip to c:\temp\ and try running the sequence. Choosing 1000 loops almost always causes the file to be locked. Less loops and the problem appears more intermittant.

If you do any one of these three things, the problem appears to go away
* remove command.com from the LaunchExecutable call in the user interface callback
* remove fputs call from the user interface callback
* change the write functions in writeafile.dll to use fopen/fputs/fclose

Any ideas on what is going on here? Our workaround for now is to change the write functions to fopen/fputs/fclose, but I'm concerned there could be problems in other places that I'm not aware of. We are investigating user interface crashes and I want to make sure this callback is not a factor.

Thanks,
Dave

[Lars_L]

Hey Dave,

I downloaded your files and I'm experiencing the same issues on my computer. Although you are closing your file reference after every loop, it is not generally recommended that you repeatedly open, write to, and close a file so many times so quickly. In general, it is good practice to open the file before the loop, write the necessary data or text within the loop, and then close the file after the loop completes. Opening and closing files can be a fairly intensive process and you can save processing power by doing only doing this when you are beginning and ending your editing. Try this method and see if lockup still occurs with the same number of writes.

You could also check and see if this a computer resource related issue by varying the delay time in WriteFileDebug.c to see if it has any effect on the number of loops before locking up.

Lars

[dseel]

Hi:

Thanks for your reply.
The loop is emulating what we are doing in our application. In reality, multiple functions across multiple DLLs are writing one line to the same file in rapid succession, each having to open and close the file so the other functions can then also write to the file.

Yes, this could be rewritten, but it would be a significant amount of work.

Any idea why the CVI file functions (OpenFile/CloseFile) cause a lock, but using the ansi C functions (fopen/fclose) do not?

Thanks,
Dave

[Lars_L]

Hey Dave,

I've been looking into your issue and so far I've got it isolated down to a TestStand issue because I had no problem deleting the file when running the source code within CVI. I have a few more troubleshooting steps to try to further limit the number of causes of the lock-up and I will let you know what I find out.

Regards,
Lars

[dseel]

Yes, we found the same thing. We could not reproduce the problem when running in a stand alone CVI executable. Looking forward to hearing your results.
Cheers,
Dave

[Lars_L]

Hey Dave,
So I've been working with your files and I think I've found the cause of your issue. First of all, though, here's what I've done so far.

1. Ran the original Writeafile.seq with the TestExec.exe user interface and experienced the locking of WriteFile.txt when the number of iterations is 1000. No locking occurs when a small number (~50) of iterations is specified.

2. I rebuilt the WriteFileDebug.c file into a .dll and experienced the same behavior.

3. When I ran the original Writeafile.seq file within my own TestStand Sequence Editor I did not experience any locking of the file.

4. I then ran this same sequence file within the included TestStand Operator User Interface instead of your TestExec user interface. When I did this the file did not lock up.

Although I'm not sure what exactly you've changed from the original TS User Interface it seems that these changes are the root cause of your issue. You could try using a differ program to try and point out the differences between your and the default user interface.

Regards,
Lars

[dseel]

Hi Lars:

As I mentioned in an earlier post, the only modification I made to the included teststand user interface was a timer callback (for this example). This callback is called every second, and includes a launchexecutable call that calls upon command.com. The source code is attached to the earlier post.

WIthout this callback, yes, everything works. I still don't understand why there is a conflict though.

Cheers,
Dave

[Lars_L]

Hey Dave,

I've verified that if you omit the LaunchExecutableEx line then the code runs fine and I agree that this is puzzling. I'm currently still working on troubleshooting this issue but in the meantime I have found that increasing the Timer control interval to 10 seconds seems to prevent the locking up.

Can you give me a better idea of your overall application architecture and more specifically what and why you are writing to a file every second while the user interface itself is open?

[dseel]

Hi:

Thanks for continuing to investigate this issue.

The primary purpose of the callback is to update a timer that we added to the execution display to show how long a sequence has been running (hours, minutes, seconds). This is why it is called every second.

The secondary purpose of the callback is to update a file with the currently executing teststand step. We have been investigating numerous operator interface crashes and trying to determine the cause. By writing the step name to a file, we can tell at what point the sequence or process model was at when it crashed (or at least, that the step was executed within the last second). This has helped us find and eliminate several issues (mostly memory leaks in the modified operator interface code or supporting sequence DLLs), though we are still seeing numerous crashes.

Cheers,
Dave

[Lars_L]

Hey Dave,
I think having the callback is a good way to update how long the UI has been running but I think there might be another way to update a file with the currently executing TestStand step.  There's actually a UIMessage called Trace that is fired after every step (and before the beginning of a step group). You could use that message to write the currently running step. In addition, because several (or hundreds) of steps could run a second, you could monitor the last write time and only record this every few seconds. By separating these two functionalities we can hopefully isolate this issue down a little further.

Basically we need to find a workaround for the LaunchExecutableEx line since in my testing commenting this out fixed the file locking.

Let me know,

Lars