LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Crashed exe leaves FP open

Hi,

 

I have a problem with an executable I built.

It shows up when I provoke an error in it that I found (Labview: Memory full).

 

The problem is the main vi's FP stays open after the crash - that's not how I'd like it to behave on a customers machine.

 

I will of course fix this memory error now that I found it, but I'm wondering how I could keep the executable's window from staying open whenever a similar bug goes unnoticed.

Setting it to close FP if it was originally closed didn't help.

Any ideas?

 

Labview ver.: 12.0.1f5 (32 bit)

on Win7 64 bit

 

Best regards

Florian

0 Kudos
Message 1 of 4
(2,519 Views)

Florian,

 

the problem is that the execution is stopping right at the function which is creating the error. So all code after this function does not execute anymore.

Therefore, the "close after execution" is not handled correctly as execution is terminated in an unexpected way.

 

I am not aware that you can react on this situation in a programmatic way within the application itself as the application terminates early....

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 2 of 4
(2,498 Views)

Norbert,

 

thanks for answering. I agree that handling this pragmatically seems impossible.

I had hoped for some switch in the vi properties making it so that if such a crash occurs the vi window is closed although the code stopped executing.

I thought it might be possible - since any LabVIEW executable requires the RTE to be present - that the RTE could clean up after my unruly vi.

 

Anything in that direction? Maybe some ini switch I could distribute together with my executable?

 

Best regards

Florian

0 Kudos
Message 3 of 4
(2,489 Views)

Florian,

 

as already stated, i am not aware of any way to react within the application itself on this situation.

A workaround could be to create some kind of "sanity check service" which observes the functionality of the application.

 

The idea is that the application starts the service as background service and provides for example a "lifebit" to the service once per 10 seconds (or whatever timeframe).

If the service does not detect the lifebits (also sometimes called "heartbeat"), it automatically shots down the application process and stopping itself afterwards.

 

To manage graceful functionality if the application closes properly, it should send a shut down command to the service.

 

Norbert

 

PS: This is ONE possible solution to address this. There might be other ones, even better ones.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 4 of 4
(2,458 Views)