Getting out of "internal error"

[mike5]

The following thing happened to me a few times now, and I suspect to others as well:

I have a largish LVOOP framework I'm developing, and sometimes I need to refactor some of it because of some design changes. A few times this results in LabView crashing with the dialog about failure in some cpp (exec or something) module. I know this is the result of the project being in a broken state while refactoring was going on and now some VI is "internally" broken.

I'm looking for a way to reliably get out of it. For minor changes, I have simply discarded the changes and repeated the process. This usually results in a working change. Other times it also helps to commit the broken project, remove it from the hard drive and check it out again. But sometimes the changes are too big to "simply redo" and the second method doesn't work as well.

So what other options do I have? Mass compile doesn't help. I know that my changes are logically correct, but LabView doesn't agree. Or even if the app contain bugs, I would like to debug it not "redo from scratch"...

Br, Mike

[jgcode]

The following thing happened to me a few times now, and I suspect to others as well:

I have a largish LVOOP framework I'm developing, and sometimes I need to refactor some of it because of some design changes. A few times this results in LabView crashing with the dialog about failure in some cpp (exec or something) module. I know this is the result of the project being in a broken state while refactoring was going on and now some VI is "internally" broken.

I'm looking for a way to reliably get out of it. For minor changes, I have simply discarded the changes and repeated the process. This usually results in a working change. Other times it also helps to commit the broken project, remove it from the hard drive and check it out again. But sometimes the changes are too big to "simply redo" and the second method doesn't work as well.

So what other options do I have? Mass compile doesn't help. I know that my changes are logically correct, but LabView doesn't agree. Or even if the app contain bugs, I would like to debug it not "redo from scratch"...

Br, Mike

Hi Mike

To clarify are you saying that the crash is corrupting your VI/.lvclass file?

[mike5]

Hi Mike

To clarify are you saying that the crash is corrupting your VI/.lvclass file?

No, the other way around. During refactoring you change some VIs, remove some existing ones, things like that, and that results in a lot of broken VIs throughout the code. You slowly work your way through all the reported errors, fixing code to reflect the new API, and when you're done the App crashes. The only problem is locating the one VI that is "internally broken" (shows no errors or anything and uses only VI that you know are working).

On a brighter note, I managed to do it this time. The trick was to instruct the LV to "send a report". This gives you the log file which you can inspect, and where it actually tells you which VI is causing the crash. I opened that VI, placed most of the code in disable structure, saved, run. Woohoo - no crash! Remove disable structure, run again and it is working.

It only didn't occur to me how to locate the offensive VI before I posted. I guess I need more mileage.

But it would be great if I didn't have to preform this dance and wave the dead chicken at the computer to have it working

Mike

[shoneill]

No, the other way around. During refactoring you change some VIs, remove some existing ones, things like that, and that results in a lot of broken VIs throughout the code. You slowly work your way through all the reported errors, fixing code to reflect the new API, and when you're done the App crashes. The only problem is locating the one VI that is "internally broken" (shows no errors or anything and uses only VI that you know are working).

On a brighter note, I managed to do it this time. The trick was to instruct the LV to "send a report". This gives you the log file which you can inspect, and where it actually tells you which VI is causing the crash. I opened that VI, placed most of the code in disable structure, saved, run. Woohoo - no crash! Remove disable structure, run again and it is working.

It only didn't occur to me how to locate the offensive VI before I posted. I guess I need more mileage.

But it would be great if I didn't have to preform this dance and wave the dead chicken at the computer to have it working

Mike

I have seen things like this before. Especially conflicts can be a real pain in the rear to fix. I often have conflicts (due to messing around in my file hierarchy) which are seemingly cyclical in nature and the IDE gives few clues as to where to start.

I had another case today where parallel loops were (seemingly) crashing my program. Hard crashing, LV just disappeared and so on. Occasionally I would get a "not enough memory" error. I removed the parallelisation of the for loops and it started working again.

I really really really want NI to focus more on stability.

Shane