Crash in application by using TestStand 4.0 and CVI labWindows 8.01

[dug9000]

Kaustubh,

You say that a VI is running in it's own thread. Do you mean a TestStand thread? If so are you using the asyncronous VI call step type or are you using a sequence call specified to use a new thread? Either way, what parameters are you passing into the VI from TestStand, and, if any are TestStand objects, what methods and properties are you accessing on them?

It is possible for a VI, even running in an external labview process, to lead to memory corruption in the TestStand process if it makes API calls back into TestStand. One possibilty is that the VI running asynchronously might be accessing data in TestStand in a way which is not thread safe. Please give us more details about what sort of TestStand API calls your VIs are making, especially the asynchronous one, and I might have some more ideas for what the cause might be.

Also, if you suspect the asynchronous VI is leading to the problem, you might be able to reproduce it in a simpler case if your simpler case is made to do something similar, so you might want to try that if you haven't already.

-Doug

[herosphro]

Kaustubh,

It seems like this issue could take a great deal more time to troubleshoot, therefore I think the best procedure might be to communicate directly with you about the problem (as was done with the previous customer in this thread).  This should make it easier to get information and hopefully ensure a quicker response time.  To facilitate this, we can get your email address from the forums, but we need your permission to do so.  If you agree, please indicate it in your next post, and then we will contact you directly and continue working on this problem.  Thanks!

[kbsave]

Hello Doug, John

Thanks for your reply.

1. The VI is called in a subsequence which runs in a new thread.

2. The thread has "RunState.Thread.ExternallySuspended" set to true for debugging.

2. The VI has "Sequence Context" as IN parameter.

3. The VI use "Get property value" and "Set property value" functions which internally use the TestStand APIs.

The "Get property value" function is used once while entering the VI. The "Set property value" function is used multiple times but with an interval of 5 to 10 minutes and not frequently. These functions are used to update a numeric variable (fileglobal) in the teststand sequence.

Also there are shared variables used in the same VI to communicate with other code modules.

Just one more question regarding the memory corruption. If the above APIs are corrupting the memory of Sequence Editor, why that VI is in the strange condition as mentioned in my previous post?

John:

I would be glad if you can use my email ID to communicate directly for helping me in solving this issue.

Thanks,

-Kaustubh

[dug9000]

Where and how exactly are you setting RunState.Thread.ExternallySuspended? Setting to true at the beginning of your VI's code and false at the end? Or are you setting this in an expression or something before calling the VI? Generally you should only set RunState.Thread.ExternallySuspended inside of a code module (true at the beginning and false at the end) and not in separate steps within a sequence.

It isn't necessarily memory corruption, but what could be happening is that your VI is making a call into teststand and that call is not returning or is crashing internally in TestStand and thus the VI is in a bad state. John or someone will contact you and help troubleshoot this issue further as it will likely be helpful to get crashdumps and other information.

-Doug