unexplained repeatable Labview crashes

[kamocat]

Something really weird is happening:
Labview is crashing on the second iteration of this FOR loop, right after the breakpoint (I assume it's in the "match pattern"). It happens without the breakpoint too, but the breakpoint makes it easier to investigate.

When you continue execution on the second iteration, Labview quits abruptly (as soon as the data gets to that Match Pattern function). The weirdest part is that it doesn't detect the internal error. When you start it back up, it doesn't generate an internal error report, and it hasn't even created a crash log.
However, checking my system console, I find that there has been an error log created by the OS. (It's 600kb, so I uploaded it as a zip rather than a txt)

Reference info:
OS: 10.4.11 (Labview says it's 10.4.9)
Processor: 1.33 GHz PowerPC G4 (512MB)
Labview: 8.5 Student Edition (it was in the 2008 KOP)

NOTE:
The error is occurring in the "store VI info" subvi
The breakpoint should open it up for you.
In order for the FOR loop to actually execute for 2 or more iterations, you must select a directory that contains 2 or more VIs or CTLs. I would recommend selecting a directory with less than 50, so you don't have to wait too long (for the first subVI to list the directory contents and then use references and property nodes to extract useful info) before you can examine the execution of the second subVI.

[Greg McKaskle]

It looks like a compiler bug that has since been fixed. I tried it on LV8.5.1 Mac version, and it runs fine when run on the directory of source you sent. I went past the breakpoint about eight times.

The crash log shows that an internal callback, part of the string processing library accessed bad memory when copying from one buffer to another. This almost certainly means that it was passed a bad parameter by the code LV generated.

So I can explain it, but I can't tell you a workaround -- because I can't reproduce it. My guess would be that you can jocky the string or cluster code around a bit, use shift registers instead of feedbacks, or something similar and you may be able to find a way of coding it that doesn't hit this error. Or better yet, see if you can find a newer version.

Greg McKaskle

[DonRotolo]

Are you having trouble downloading new code to the cRio? If so, PM me and I can try to explain an issue we identified and eventually showed to the NI team at championships.

Don

[Greg McKaskle]

This issue is with LV running on a Mac, so no RT download, no cRIO.

Greg McKaskle

[kamocat]

Thank you!
The shift registers successfully avoided the error.