Jump to content

Crash LabVIEW with events


eaolson

Recommended Posts

I was brushing up on my events and discovered this interesting crash using two of the NI-provided examples:

1. Open <labview>\examples\general\dynamicevents.llb\Dynamically Monitor VI's.vi.

2. Run the VI.

3. Open <labview>\examples\general\dynamicevents.llb\Dynamically Register for Events.vi

4. Run the VI.

5. Do not stop the "Dynamically Register" VI. Instead, close it by clicking the "X" in the upper right corner of the window. A dialog window will pop up asking "Do you really want to close 'Dynamically Register for Events VI'?". Click "Yup".

6. Stop the Dynamically Monitor VI by either using the Stop button on the front panel or the Abort Execution button.

7. LabVIEW will crash with a "LabVIEW.exe has generated errors and will be closed by Windows" window.

I've observed this on 8.20 running under Windows 2000 and XP. Can anyone verify that it does happen on 8.5? I haven't really figured out where it happening, but it's probably at either a property node or a Register for Events node.

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

Link to comment

I was brushing up on my events and discovered this interesting crash using two of the NI-provided examples:

1. Open <labview>\examples\general\dynamicevents.llb\Dynamically Monitor VI's.vi.

2. Run the VI.

3. Open <labview>\examples\general\dynamicevents.llb\Dynamically Register for Events.vi

4. Run the VI.

5. Do not stop the "Dynamically Register" VI. Instead, close it by clicking the "X" in the upper right corner of the window. A dialog window will pop up asking "Do you really want to close 'Dynamically Register for Events VI'?". Click "Yup".

6. Stop the Dynamically Monitor VI by either using the Stop button on the front panel or the Abort Execution button.

7. LabVIEW will crash with a "LabVIEW.exe has generated errors and will be closed by Windows" window.

I've observed this on 8.20 running under Windows 2000 and XP. Can anyone verify that it does happen on 8.5? I haven't really figured out where it happening, but it's probably at either a property node or a Register for Events node.

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

Link to comment

QUOTE(eaolson @ Nov 21 2007, 04:23 PM)

I was brushing up on my events and discovered this interesting crash using two of the NI-provided examples:

1. Open <labview>\examples\general\dynamicevents.llb\Dynamically Monitor VI's.vi.

2. Run the VI.

3. Open <labview>\examples\general\dynamicevents.llb\Dynamically Register for Events.vi

4. Run the VI.

5. Do not stop the "Dynamically Register" VI. Instead, close it by clicking the "X" in the upper right corner of the window. A dialog window will pop up asking "Do you really want to close 'Dynamically Register for Events VI'?". Click "Yup".

6. Stop the Dynamically Monitor VI by either using the Stop button on the front panel or the Abort Execution button.

7. LabVIEW will crash with a "LabVIEW.exe has generated errors and will be closed by Windows" window.

I've observed this on 8.20 running under Windows 2000 and XP. Can anyone verify that it does happen on 8.5? I haven't really figured out where it happening, but it's probably at either a property node or a Register for Events node.

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

IM no architect but

I had discovered this exact behaviour a few months ago when I was trying to learn how to use events beyond the simple UI stuff.

Got feedback here that it was a crash on 8 and 8.2. Sorry I never tried to get at the bottom of it but

Is this not an NI example?

What what I can tell you that event structures can be dangerous creatures

if not handled properly. I have learned the hard way and I will not use them (or notifiers) for anything fancy.

As to NI thinking it is not a bug I kind of wonder if they might be a little overwhelmed

at the moment.

Link to comment

QUOTE(eaolson @ Nov 21 2007, 04:23 PM)

I was brushing up on my events and discovered this interesting crash using two of the NI-provided examples:

1. Open <labview>\examples\general\dynamicevents.llb\Dynamically Monitor VI's.vi.

2. Run the VI.

3. Open <labview>\examples\general\dynamicevents.llb\Dynamically Register for Events.vi

4. Run the VI.

5. Do not stop the "Dynamically Register" VI. Instead, close it by clicking the "X" in the upper right corner of the window. A dialog window will pop up asking "Do you really want to close 'Dynamically Register for Events VI'?". Click "Yup".

6. Stop the Dynamically Monitor VI by either using the Stop button on the front panel or the Abort Execution button.

7. LabVIEW will crash with a "LabVIEW.exe has generated errors and will be closed by Windows" window.

I've observed this on 8.20 running under Windows 2000 and XP. Can anyone verify that it does happen on 8.5? I haven't really figured out where it happening, but it's probably at either a property node or a Register for Events node.

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

IM no architect but

I had discovered this exact behaviour a few months ago when I was trying to learn how to use events beyond the simple UI stuff.

Got feedback here that it was a crash on 8 and 8.2. Sorry I never tried to get at the bottom of it but

Is this not an NI example?

What what I can tell you that event structures can be dangerous creatures

if not handled properly. I have learned the hard way and I will not use them (or notifiers) for anything fancy.

As to NI thinking it is not a bug I kind of wonder if they might be a little overwhelmed

at the moment.

Link to comment

QUOTE(eaolson @ Nov 21 2007, 08:23 AM)

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

Whoever at NI told you it's not a bug was probably smokin' the good stuff :P . I can reproduce it even with a blank new VI with a while loop and not using the "Dynamically Register for Events.vi"

Link to comment

QUOTE(eaolson @ Nov 21 2007, 08:23 AM)

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

Whoever at NI told you it's not a bug was probably smokin' the good stuff :P . I can reproduce it even with a blank new VI with a while loop and not using the "Dynamically Register for Events.vi"

Link to comment

QUOTE(Michael_Aivaliotis @ Nov 21 2007, 03:44 PM)

Whoever at NI told you it's not a bug was probably smokin' the good stuff :P . I can reproduce it even with a blank new VI with a while loop and not using the "Dynamically Register for Events.vi"

I haven't quite nailed this down yet, but I think that's because the problem is actually happening inside Dynamically Monitor VI's. That keeps an array of running VIs and registers the Panel Close event for each one. I'll try and look into this more this weekend. (Over the holiday, does that make me a geek?)

For even more fun and excitement, there's this odd chain of events, too:

1. Open Dynimically Monitor VI's, Dynamically Register for Events, and Wait for Events (which is a subVI of Dynamically Monitor VI's).

2. Open the Wait for Events block diagram.

3. Run Dynamically Monitor VIs and Dynamically Register for Events

4. Turn on execution highlighting in Wait for Events.

5. As before, close Dynamically Register for Events with the X in the window corner

6. Wait for Events will process all the events it's supposed to, but LabVIEW won't crash.

7. Again, open Dynamically Register for Events. The program will open and you'll notice that the Run button indicates that it's already running! LabVIEW will then crash.

Link to comment

QUOTE(Michael_Aivaliotis @ Nov 21 2007, 03:44 PM)

Whoever at NI told you it's not a bug was probably smokin' the good stuff :P . I can reproduce it even with a blank new VI with a while loop and not using the "Dynamically Register for Events.vi"

I haven't quite nailed this down yet, but I think that's because the problem is actually happening inside Dynamically Monitor VI's. That keeps an array of running VIs and registers the Panel Close event for each one. I'll try and look into this more this weekend. (Over the holiday, does that make me a geek?)

For even more fun and excitement, there's this odd chain of events, too:

1. Open Dynimically Monitor VI's, Dynamically Register for Events, and Wait for Events (which is a subVI of Dynamically Monitor VI's).

2. Open the Wait for Events block diagram.

3. Run Dynamically Monitor VIs and Dynamically Register for Events

4. Turn on execution highlighting in Wait for Events.

5. As before, close Dynamically Register for Events with the X in the window corner

6. Wait for Events will process all the events it's supposed to, but LabVIEW won't crash.

7. Again, open Dynamically Register for Events. The program will open and you'll notice that the Run button indicates that it's already running! LabVIEW will then crash.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.