LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug: Labview 8.5 consistently crashes on loading this vi

Something weird happened to me...    I was editing my program, and noticed a spelling error in one of the Type Definitions.   So I right-click to 'Open TypeDef' to correct it.   On saving the Type Def, my Labview completely crashed.   
 
Since then, I cannot open my main program anymore.  Labview always crashes upon loading it.    I can load the Type Def, and the spelling error has been corrected. But apparantly something is still messed up...
 
What's really a problem, is that previous versions of the vi, and the backup from before it crashed, also produce this crash...    Basicly, I can't open any recent version of the program.    I'm not quite sure what's going on, but it's extremely annoying...   
 
Other vi's do work normally.... it doesn't seem that Labview itself is affected...     It seems that any vi that has a reference to the Type Def crashes, althought the type def loads normally in Labview...
 
Maybe some of the blue boys can check the vi and type def, and see what's going on? 
 
Running  Labview 8.5,  Windows XP SP2.  
Download All
0 Kudos
Message 1 of 18
(4,152 Views)
Anthony,

I was able to load it without any problem except for the dozens of missing subVIs and typedefs. I never saw the error list have a More errors.. item before.

LV 8.5 on Mac OS X 10.4.11.

Lynn
0 Kudos
Message 2 of 18
(4,143 Views)
Well...   It's a rather big program (for my standards anyway Smiley Wink  ) so  I didn't upload all the sub-VI's and stuff, because I was pretty convinced that the problem of the crash lies in these two files.    Maybe I should have done a complete source distribution...   
 
I've been doing more messing around, and I could get the application vi to load, when I emptied the Type Def.  I then filled in the Type Def from scratch, and now it works..    I think that means that the problem was lying in the Type Def after all...     I hope the Blue's will have a look at it, to see if there's anything weird in it...   It shouldn't crash Labview like that...
 
 
Thank God it works again....   When I saw that even the backup and previous versions produced the same crash, I was very much afraid that I'd simply lost the program.   
A guess I had bit of a panic attack...          
0 Kudos
Message 3 of 18
(4,119 Views)
Glad you got it going again.

I would make a new set of backups and verify that all the corrupted copies have been removed. You don't want to go back to an earlier version and have the problem show up again!

Lynn
0 Kudos
Message 4 of 18
(4,111 Views)
Before you delete everything, we would really like to have a copy of the non-functioning code so we can attempt to debug it.  Can you zip it up and post it?  Please include as many details of exactly what was open and exactly what changed to create the error as you can.  This will increase our chances of finding the error.

In general, it is usually safer to edit typedefs with nothing else open.  The next normal load will then update the calling VIs.
0 Kudos
Message 5 of 18
(4,080 Views)
It seems a bit difficult to figure out what exactly is the non-functional code....
 
I thought it was the type def and vi that I attached to the original post, but from Lynn's response, it's clear that it isn't... 
 
I now think that maybe one the of the other subvi's that used the type def was causing the crash.   Unfortunately, I allready replaced the controls in those subvi's with the new one.    At the moment, I can't reproduce the crashing of Labview upon loading of the main vi anymore.   If I replace the type def with the 'faulty one'  it loads normally, and gives the normal error messages...
 
I am able to reproduce the crash upon renaming the contents in the type def.   This typedef is a cluster with some 20 refnum's to front panel controls.  When I open the type def from within the main program, and then rename one of the refnums, and leave the type def editor by double-clicking the topleft icon of the window, I consistently get a Labview crash...    This time however, I didn't get problems in loading the vi's afterwards...   Just the type def crashed.
 
The problem is that I cannot reproduce this typedef renaming with a small example program...  Only with the main program.   So I  don't really know where the real problem is...    If you want a functional program code, then you'll receive a zip with some 200 vi's of 6 MB's total...    Is that OK with you guys?      I can tell you exactly what to do to produce the crash in renaming the typedef content. 
 
 
0 Kudos
Message 6 of 18
(4,065 Views)
A silly suggestion, perhaps, but maybe you have a copy of the typedef somewhere with the same filename on your hard drive, and LabVIEW was trying to load that copy instead for some reason? That might explain why someone else was able to open it.
0 Kudos
Message 7 of 18
(4,056 Views)
Good suggestion.   But no, there weren't any other files with the same name. 
0 Kudos
Message 8 of 18
(4,038 Views)

6MBs should not be a problem if you don't mind posting your source on a public forum. If you'd rather, you can send it to our email support. It would be good for us to get it though, because this sounds like something that has not been previously reported. Without us being able to recreate the problem here, this bug is likely to remain.

I know Damien has learned to play things very safe partly from being exposed to a lot of prerelease builds. I don't want our customers to get paranoid about editting typedefs though. It should not be a problem to edit typedefs with other VIs in memory. In this specific case, it doesn't even sound like that would have helped. Since LabVIEW crashed both when the change was applied in memory and when the VIs were reloaded from disk, it seems that the problem is with applying the changes regardless of how they were made.

If you can tell us how to reprocude the problem, we will be able to correct it in a future version.

0 Kudos
Message 9 of 18
(4,033 Views)

Hi Greg,

I've attached the complete source code as requested.

To reproduce the crash during editing of the type def, do the following:

Open Isabel v5.1.vi  in Isabel.lvlib, and open the block diagram. In the bottom left corner, at the very left, there's a constant called 'General Control Reference's.  That's a type def constant.    Right click, and select 'Open Type def.'    Then rename one of the controls in the type def, and close the type def.    At that point, Labview crashes.    THAT crash is reproducable using these vi's in the project.  (at least on my computer...  )      I couldn't reproduce it with a simple newly made vi and type def...

I have not been able to reproduce the crash where Labview also crashed on trying to load the vi...    I still don't know why that happened...  Maybe because of the sub-vi's that use the type def as well.  (For example the save parameters & load parameters vi's)     One thing I did notice...  When Labview crashes during renaming the type def, it hasn't saved the renaming.  If I remember correctly, in the case that Labview crashed during startup as well, it had renamed the type def . 

Hope this helps in correcting the issue.   

0 Kudos
Message 10 of 18
(3,987 Views)