LabVIEW
LabVIEW crash with Copy.vi from network path (windows 10 1803)
Solved!
Hi Ironman,
This is with log. Bug still present.
Surely the bug is not solved by implementing a log function…
Somehow LV recurse indefinitely. There is a clear stop recursion condition in my code.
The same code runs DIFFERENTLY with local folder input and share folder input.
The point is: at which folder/file does your routine start to recurse forever?
Can you recognize a pattern?
What is stored in your log? (Can you attach the log?)
I cannot run your VI due to missing OGTK subVIs. I haven't installed OpenG and will not do…
Maybe there is some unhandled file error that is keeping your code to end the recursion from executing? (Maybe you never see the error because LV crashes out first.)
This is the "File Exists_OGTK.vi" code. You can just replace it , you dont' need OpenG.
In the Log I append record of { time , SourceFilePath , DestFilePath } after a successfull copy.
What I see in the Log is this:
- when using local folders : a record (row) for each and only file copied (it's OK, as expected)
- when using network folder as source path : it is stuck into coping the same three files ( 1 , 2 , 3 .... 1, 2, 3 ..... 1, 2, 3 , forever). If you set the vi to "show clone FP", you will get infinite windows. I also added a (useless) check BEFORE invoking recursion: if the folder has empty subfolders (empty array), there is no call to recursion. Somehow labview runtime runs the recursion, that is it calls infinite times, even when there is no condition met!
I am using .NET dll call as workaround now, if someone of you can forward my VIs to NI, they can test my code, I am 99,9% sure it's a serious NI bug.
It's a AAA bug critical 😄
thanks and have a nice day
Well so far we know that you have a Windows 2016 Server, a Windows 10 client build 1803 and that if you access a shared directory of the server you will get a crash. And if you reconstruct the Copy yourself you see that it keeps looping on the same three files.
To call this a LabVIEW bug is still kind of premature. Apparently something in your server config makes the Windows API that LabVIEW calls return the same three files over and over again. There might be a factor that causes LabVIEW to misbehave but the root cause seems more in something in the new Windows build that makes the Windows APIs FindFirstFile() and FindNextFile() misbehave for the path in question. There might be no shortcut files (which are really old Windows 95 workarounds for missing proper symlinks in the OS) but there might be still symlinks (NTFS junction points) in the server that create a recursive directory list.
You keep shouting here and claim lots of things but you have not delivered substantial evidence that has been repeatedly asked from you, such as the log file you say shows what is happening. And my preliminary tests after Microsoft finally frocefully pushed on me its latest Windows update yesterday have not evidenced the behaviour you see, so that is another indication that it has to do something that is specific to your server configuration.
Hi ironman,
end recursion when the next call gets the very same inputs as the previous one! (OR the input is empty)
As said before: you need to employ checks to avoid unlimited recursive calls!
I'm about 99.99% sure that the included modification to your DirectoryCopy.vi will fix the issue for your LabVIEW VI, though it won't fix the LabVIEW built in Copy File function. Personaly I would avoid the recursive VI call altogether and rather build a stack of directory paths to enumerate and at each iteration add the directory entries from List Folder to that stack. Such stack based operation may seem more trouble at first but usually are not more complicated to build, and a lot easier to debug and control.
The problem that here happens is that Windows used to return the "current directory" entry (.) and the "parent directory" entry (..) always as the first two entries when enumerating directory entries and the LabVIEW List Directory function filters them as they make no sense to be returned in the list of directories. But this filtering assumed that those entries are always returned as the first two entries. Samba served file systems seem to break that assumption as they can easily provide other file entries that start with a non-alphanumeric character that can happen to be alphabetically sorted before those "current directory" and "parent directory" entries. Maybe something in your system setup also causes this to occur for your Windows 2016 server share.
Since the recursive File Copy variant internally makes use of the same List Folder function that the according List Folder node uses, it is also prone to this problem.
NI seems to have fixed that in either LabVIEW 2016 or 2017 as evidenced in this post. So upgrading your LabVIEW version is another option to even make the File Copy node work for your setup. The crash in the LabVIEW File Copy function is not because the function is recursively calling itself, which it isn't, but at each iteration it adds the current directory entry to the stack of paths to enumerate so that that stack will keep growing and eventually LabVIEW runs into a fatal out of memory error.
Of course if you had gone debugging the VI even for a few iterations you would easily have seen that there is most likely a "." entry returned as file directory and the LabVIEW path functions interprete that as the same directory as the path without this "." file name.
Did you really test with LabVIEW 2018? According to the link I gave in my previous post, the issue with Samba served shares from Linux computers was not present in 2017 and 2018 anymore.
As to who is the bad guy, this obviously started to break for you due to Windows 10 build 1803. Your claim that Microsoft is not going to fix this is possibly not right because there are likely other much bigger fish than NI who somehow and somewhere, relied on this behaviour and will scream fire and war at Microsoft for this. Back in 1992 when large parts of the low level system interfaces in LabVIEW were developed to work on the various platforms, this kind of assumption about the workings of FindFirstFile() and FindNextFile() in the Windows API was actually present in example code from Microsoft. It also prevented the code from having to compare at every iteration of FindNextFile() if it was one of the special directory entries and such string comparisons done in a loop lots and lots of times was considered very CPU costly at that time.
Sure NI can and probably will improve the code, if they haven't already done as indicated in the other link, to make the code more stable in general but breaking API functionality is always a bad thing, even if it is sometimes unavoidable. In this case I doubt it is unavoidable but probably due to some optimization either intentionally or because of a different compiler setting when they build Windows 10 or a certain part of it.
Considering that Windows 10, Build 1803 was officially released on July 7, 2018, the right course of action would be to POLITELY report this to NI as a bug report , and not to scream in a public forum that this is a scandalous bug.
