LabVIEW Project Providers

cancel
Showing results for 
Search instead for 
Did you mean: 

LV crash caused by mxLvGetFilePathBatch.vi

So, I have been chasing a very elusive bug for 2 days now and I have finally distilled it down to it's core.

I'm not going to get into how I got here, but suffice to say, I have a need to run the code attached to this post, albeit a more complicated version.

I have used mxLvGetFilePathBatch.vi quite a bit throughout the TSVN Toolkit and have never seen this before. It appears that sometimes this VI corrupts memory on the output, which causes Compare Two Paths.vi to crash when executing the Path to Array of Strings function on Path 2 input.

Here's some of what I have observed:

  • This occurs with any VI that tries to do a comparison. I believe that the array of paths out of mxLvGetFilePathBatch.vi is corrupt.
  • I see error 1097 in the crash log and in DETT, but almost never on the output error wire following mxLvGetFilePathBatch.vi.

Attached is the code that causes this crash.

I believe I have a workaround, but won't know until I try. Any immediate ideas on working around this crash would be greatly appreciated. This is holding me back from completing some much needed changes.

Download All
0 Kudos
Message 1 of 11
(5,541 Views)

Always Copy to the rescue.  If you add an always copy on the array of paths before going into the for loop it no longer crashes, but does return an error about the type of path provided.

0 Kudos
Message 2 of 11
(5,479 Views)

Thanks Brian. I discovered that as well and was able to move on.

This should still result in a CAR, but it will be long worked around in my code by the time it gets fixed.

0 Kudos
Message 3 of 11
(5,479 Views)

Always Copy allowed me to move forward, but unfortunately I am now getting these crashes again when mxLvGetFilePathBatch.vi happens to be called during a build. All instances of this VI that I use are now immediately followed with Always Copy and LV still crashes with corrupt memory from this VI.

@NI: any ideas?

0 Kudos
Message 4 of 11
(5,479 Views)

Hi Eric,


Sorry for the delay, but I've been out of the office the past few weeks.  I did some preliminary digging on this VI internally and the only reference to it I could find were some bug reports of customers who happened to be using TSVN, so it looks like it's not a terribly high used VI.  I honestly haven't used the Provider framework myself in a few years, so you are probably more of an expert than I am, but I can try to run this by a developer to see if they have any suggestions.

Before I do so though, have you tried simply using the "mxLvGetFilePath.vi" in a loop?  I think theoretically these should provide the same results, just might be a bit slower.  However if it doesn't crash and the performance difference is negligible, perhaps this could be a suitable workaround until this gets fixed in the future.

Thoughts?

David

0 Kudos
Message 5 of 11
(5,479 Views)

Hi David,

Thanks for chiming in. I get the same error + crash from mxLvGetFilePath.vi when used in a parallel for loop. When I turn off parallelization LV crashes around roughly the same time during build of my test project, but without NIER capturing the error.

I have a provider that I use to get more visibility into when certain things are actually happening and dump them to a log. It appears that during a build many (30 in this case) temporary projects are loaded by LV. Those temporary projects contain many of the VIs in the original project. In the "old" toolkit, as each of these items is loaded, the toolkit would get the path of each item, query its SVN status, update the icon overlay and move on. This would effectively slow down the speed of the calls to GFP and GFPB (shortening for the sake of what remains of my sanity). In the "new" version of the toolkit, these are batched such that the paths are all discovered in quick succession, then when 10s-1000s are "registered" one SVN status call is made. The SVN status call is the long poll in the tent of updating icon overlays, so I wanted to reduce the number of calls. I believe that either calling GFP too quickly or too many times while a build is also going on is causing the corruption. I don't see any other reason that it would cause a crash in the "new" vs. "old".

Neither version of the toolkit ignores these "temporary projects". It would not be terribly hard to do, but I am not excited about getting into the business of selectively ignoring certain items because they conflict with other processes. What other rusty nails are lurking there and what point does it end. I may not have an option here, but I'd like to avoid it if I can. I am also worried about any workaround that does not address the underlying issue of this VI corrupting memory. I worry that it is a ticking timebomb waiting to crash LV unexpectedly.

0 Kudos
Message 6 of 11
(5,479 Views)

So far wrapping mxLvGetFilePath.vi in a VI and making that VI execute in the UI execution system seems to have fixed the crashes. My test cases no longer crash, but I want to use it for a while longer before I say that it is a solid workaround.

This was a total long shot based on a conversation with a text developer based on something he saw with a completely unrelated framework. Is it possible that the provider callback VIs operate in the UI thread and that mxLvGetFilePath.vi does not behave well out of that environment? My icon update process is not running in the UI thread and by default mxLvGetFilePath.vi just inherits from the callers execution system.

0 Kudos
Message 7 of 11
(5,479 Views)

Is it possible that the provider callback VIs operate in the UI thread and that mxLvGetFilePath.vi does not behave well out of that environment? My icon update process is not running in the UI thread and by default mxLvGetFilePath.vi just inherits from the callers execution system.

It's possible, and would not surprise me, but I don't know 100% if this is the case.  Either way, I can file the CAR to R&D and let them dig into it and figure out if it's possible and valuable to fix this.  However since there is (hopefully) a workaround you can use, then you won't need to wait for us to fix it in a future version.  Keep me updated if this fixes it in the long term or if I need to continue finding a workaround.

David

0 Kudos
Message 8 of 11
(5,479 Views)

Unfortunately, this does not seem to have completely solved the problem. My test case passed for a while on Wed after making the change and is now back to the same behavior. It appears this change was a net positive, but did not solve the problem.

0 Kudos
Message 9 of 11
(5,479 Views)

Ugh... Too good to be true of course.  I will see if I have some time this week to reproduce the issue and work out with R&D if they have any other ideas for workarounds. 

0 Kudos
Message 10 of 11
(5,479 Views)