How to debug LabVIEW crashs and freezes etc?

[LAVA 1.0 Content]

Hi,

LabVIEW 8.20 seems to have a large number of bugs that make LabVIEW either crash or freeze or corrupt the project etc. I've very patiently been sending bug reports to local NI support. They have then submitted bug reports to the head office. However the head office has refuced to investigate bugs that occur on large projects because "these are project dependent bugs and cannot be recreated in an empty project". I have managed to recreate some of the bugs with an empty project but some of the bugs really seem to occur only with large projects. As I am not NI test engineer, I cannot consume my time by trying to create empty projects that bring up bugs. Rather I need to get my projects on the right track again so that I can continue my work. Because of these kind of aswers, I've stopped sending my large projects that cause LabVIEW to crash to NI support as it doesn't help me nor anybody else and only causes extra work to local NI support.

The question is, is there any way to debug LabVIEW bugs by yourself. And I do not mean LabVIEW VI bugs but LabVIEW core bugs. I once again ended up into a project that I cannot get opened again. LabVIEW either crashes or freezes or claims that "cannot copy reentrant dataspace" depending on how I try to open the project. I have a backup from yesterday which I could revert to, but as this is a bug that keeps occurring again and again, I'd like to finally know why this bug occurs to be able to avoid it. The current project contains classified information, so this time I even cannot submit the project to NI, at least not without explicit NDA which I regret they will refuse to sign.

[Donald]

Sounds familiar... a reason extra to stay away from x.00 versions but a x.20 version should not crash during developement.

I thought 8.20 was OK, and much better than the rush-rush 8.00 version, except for the OOP part, which is most often not needed. My experience with 8.20 is very limited and only with rather small projects (<300 VIs). For mission critical I use 7.1.1. At my company we got a green light for 8.20 development ?!

I'm very interested in the scope of your problems? Are you're problems related to OOP or to the project manager?

How to debug? You can't .. this is why LabVIEW is NOT used in a lot of mission critical applications. It get even worse when you use external interfaces like ActiveX or .NET.

I find it unacceptable that a lot of LV bugs are not even in the knowledge base or in release notes. I always have to call to NI Belgium to check whether the bug is already found and thus making a bug report is waste of my (very expensive) time.

Here are some tricks however:

1) Problems with Insane Objects can be tracked down by using the Labview debugger. Searching through LabVIEW info archives and with the help of Brian Renkens website for .ini settings will learn you this profane art (I do not understand why this debugger is hidden anyway). I have not tried this for LV8+.

2) Loading problems can 'sometimes' be solved with a mass compile (a least for data.cpp problems)

3) Cross platform application loading problems could be the use of non standard fonts

4) Check for duplicate files

5) Check for llbs, vis and ctls with abnormal size (very small or very large)

[LAVA 1.0 Content]

I'm very interested in the scope of your problems? Are you're problems related to OOP or to the project manager?

Well, to be honest, I don't know. LabVIEW is not very informative when it crashes. I'm using OOP very extensively, so I assume quite many of the bugs are OOP related. It seems that there is a bug in the OOP compilation algorithm, probably not all class related constants get updated correctly, which corrupts VIs and then causes crashes. The crashes themselves occur because LabVIEW doesn't seem to properly handle exceptions, and does not check for invalid NULL pointers. One of the bugs probably relates to calling OOP VIs using Open VI reference and Call by reference node combination. The VI Type specifier constants probably do not get correctly updated when an underlying class of one of the connectors is modified and this may cause crashes. In addition some of the bugs have been project explorer related.

I've made a decission to move away from LabVIEW in the future mainly because it simply is not stable enough for our purposes. As we are developing developer toolkits this also means that NI will loose all those customers that will use our tools. The only way I can see us using LabVIEW is that LabVIEW core source code will be opened so that the community can make the core stable. In addition this would help LabVIEW to develop towards the needs of professional users and not only the needs of newcomers. I wouldn't care if DAQ related parts of LabVIEW were closed source as long as the core would be open source.

[Donald]

THX for the info, it should be the OOP as our company has less problems with 8.20 and we do not use OOP (we hate the pass-by-value implementation). I understand your decission to move away from LV. I also fear that you are not the only one.

As a die-hard fan of LabVIEW for more than 10 years I start becomming more on more jealous on the progress of the Visual Studio .NET IDE and tools. To get an idea how hard .NET/Visual Studio is improving please read the very good blog of the last TechEd in Barcelona from my collegue Bruno.

http://msmvps.com/blogs/vanDooren

The progress of LabVIEW seems to be more in the embedded design than in the modern software patterns and development practices. Where .NET technology tries very hard to avoid hard coded constants and obscured interfaces LabVIEW is moving the other way it seems.

I can not sell any LV8 license to a customer who uses LV7.1! Why should he upgrade except if he is forced because of missing toolkits/drivers (e.g. CRio)??? Yes I' m frustrated by this :-) because I'm forced to stick with lv711.

>>> Please do not read this as .NET is better than LabVIEW, it depends so much of the project and environment. But for large scale projects at least .NET seems to be a very good choice for the next 5 years. Especially the increased development time and more advanced programming skills are my fear to switch to .NET. For toolkits the development time is less crucial and the .NET market much bigger.

To what development environment would you like to switch and do you have an idea what will happen with development time?

[PJM_labview]

...LabVIEW either crashes or freezes or claims that "cannot copy reentrant dataspace" depending on how I try to open the project. I have a backup from yesterday which I could revert to, but as this is a bug that keeps occurring again and again, I'd like to finally know why this bug occurs to be able to avoid it. ...

Jimi,

I think this particular issue is due to the debugging capabilities of reentrant VI in LV 8.x. I have seen it many time both in LV8.0x and 8.2 (although less in LV8.2) and this was happening only when I was debugging a reentrant VI. I think you may be able to alleviate the issue by unchecking allow debugging of the culprit reentrant VI.

Note: I have not checked whether this work or not.

PJM

[Aristos Queue]

Jimi:

I have appreciated your adoption of LabVIEW Object-Oriented Programming (LabVOOP). Both your bug feedback and your feature feedback have been valuable. LV8.2 includes the first release of LabVOOP, and, yes, LV classes do tend to make projects unstable. This is due to, by my count, seven significant bugs that have been found since the release that will be patched in the next bug fix release. FYI, three of those bugs have been found through your testing.

I can offer you a workaround for the majority of the problems. To begin with, make sure all VIs for your application are in memory when editing the class' private data control, and always do Save All after editing the PDC. This is not necessary for most edits to the PDC, but it prevents corruptions from developing in some edge cases. If you do begin experiencing problems where the VIs become corrupt (and crash as soon as you hit the run button), then load your project and open the top-level VI and then hit ctrl+shift+run arrow on the top-level VI. This forces a recompile of every VI in memory. That rebuilds various tables from scratch completely. On a large project of 585 VIs being developed inside NI, this process takes about a full minute. After it completes, save *everything.*

The runtime system of LabVOOP appears to be stable. It's the editor environment where bugs are appearing. Within NI, I am aware of three major projects that are using LabVIEW classes (there are likely others, but these are the ones I've watched closely to get a feel for problems developers are finding). These have been able to replicate the large-project bugs to which you refer. My team has been tackling them as fast as possible. These three have hit problems, yes, but development has proceeded and seem likely to be successful.

You said you were moving away from LabVIEW for development. LabVIEW 8.2 is very stable, as measured against various prior LabVIEW releases. The next bug fix release should bring the LabVOOP components up to the quality of the rest of LabVIEW. I would be very sorry to lose you as a developer. I understand your frustrations, but I ask your indulgence. It took C++ multiple years to get compiler stabilization, and I think we're well ahead of that standard. The power of classes to the end programmer comes because the language tracks so much information on the programmer's behalf, and getting that tracking right is tricky.

The core of LabVIEW is stable. LabVOOP is not core. It is a recent extension that is being stabilized. I understand if in the short term you move away from LabVOOP. But moving away from LabVIEW as a whole would be overkill, in my opinion. You have a house with a good foundation. I'm sorry the toilet in the new bathroom keeps backing up; we'll have it fixed in short order, but in the meantime, you can live in the rest of the house, which has stood for 20 years. You don't have to move out. Our commune would miss you. And I can guarantee your new place would have poorer wiring.

-- Stephen R. Mercer

-= LabVIEW R&D =-

Lead developer for LabVOOP team

[Donald]

THX Stephen your reply does justify our green light for LV8.20 development without OOP. I was getting worried because we have a least 10 Lv8.20 projects going on (one will run in a nuclear power plant!).

[Aristos Queue]

THX Stephen your reply does justify our green light for LV8.20 development without OOP. I was getting worried because we have a least 10 Lv8.20 projects going on (one will run in a nuclear power plant!).

You're welcome.

I do want to stress that the runtime functionality of LVClasses seems to be clean, and the problems only arise while developing. In a 1.0 release, I'd be uncomfortable with LabVOOP running the control rods at the nuclear power plant, but perfectly happy if it was controlling the lawn sprinkler systems. After the bug fix release, then I'd be ok if you go create "Nuclear Power Plant.lvclass".

And, before anyone else asks, no I can't supply a date for the bug fix release.

[jaegen]

And, before anyone else asks, no I can't supply a date for the bug fix release.

I understand you can't supply a date, but can you tell us whether or not you personally know the date? (i.e. Are things far enough along for there to actually be a "date"?)

Jaegen

[LAVA 1.0 Content]

I can offer you a workaround for the majority of the problems. To begin with, make sure all VIs for your application are in memory when editing the class' private data control, and always do Save All after editing the PDC. This is not necessary for most edits to the PDC, but it prevents corruptions from developing in some edge cases. If you do begin experiencing problems where the VIs become corrupt (and crash as soon as you hit the run button), then load your project and open the top-level VI and then hit ctrl+shift+run arrow on the top-level VI. This forces a recompile of every VI in memory. That rebuilds various tables from scratch completely. On a large project of 585 VIs being developed inside NI, this process takes about a full minute. After it completes, save *everything.*

Thanks Stephen for your extensive reply. We've been using this method you proposed for about a month now and it really stabilized the development environment a lot. However it seems not to prevent all the corruptions and all the crashes. I'm afraid that there are major problems that NI development team are still not aware of. There are crashes when I press the run button even though we've followed this guideline. There are crashes when I try to Save all. There are crashes when I open projects. What I'm most afraid of is that there are corrupted VIs or other components as a result of these crashes and I have absolutely no means of finding it out.

We made a move to LabVIEW 8.20 because of LabVOOP. We were starting a major project by the time we knew that LabVOOP is going to be released. This project would have been architecturally near impossible without some sort of OOP. LabVOOP made the project possible, although lack of constructors, copy-constructors and destructors is a still a major problem. We can work around constructors, but there is no good work-around for the lack of copy-constructors and destructors. We would also need by-reference classes for some parts of the project, althougt at least in our project we also benefit from the fact that LabVOOP is not only by-reference as it scales better this way. In addition inability to create reentrant dynamic VIs causes us problems.

We need recursion and we have managed to center all the needs for recursive calls to only one VI. We have divided the recursive calls to three different VIs. A reentrant VI that is called recursively and that does all the actual processing. This VI is a static class VI that has a required class input and a recommended class output. A second reentrant VI that does the actual calling using call-by-reference-node. The first VI calls this second VI to make the call to isolate the call to a single place. Third non-reentrant VI is used to manage VI references to the first VI, opening them when there are not enough references open already. The opened references are stored to a shift register to allow fast recursive calls. This three VI structure seems to cause major problems, probably because the VI-references to the first VI opened by the third VI do not get properly updated as the class structure changes. Our project was quite stable until we added this structure. We have written it twice and both times the project became unsable after adding this structure. The second time it seems a bit less unstable than the first time.

What would make me more trusting towards LabVIEW would be totally different kind of attitude towards known bugs. and towards professional developers

• First the known problems should be public and NI should publish workarounds to these problems if there is one.
  
• Second NI should release patches to at least major bugs as they are fixed, not waiting a major service pack to be released once a year. This would help us developers to identify which bugs still need reporting and which are already fixed. Currently we have to wait for the next major release. If the problems we are encountering are not fixed in this release it may take another year until the problem is fixed. This simply is not acceptable.
  
• Third there should be a way to find out if any VIs in the project are corrupted. Current Ctrl+Shift+Run doesn't fix all corruptions and there is no way locating corruptions. The worse thing that can happen is that corrupted VIs written many years ago make application crash and there is no way for the developer to locate the problem.
  
• Fourth NI should somehow guarantee the professional developers that LabVIEW is developed as a general purpose programming language for large scale applications and not only as a tool to create very small and simple projects. Currently there is no such guarantee from NI side, on the contrary NI is putting very much effort in developing all those useless features targeted for nobrainers. If we professional developers cannot feel valued customers whose needs and opinions are listened, how can we go on using LabVIEW as a development tool.
  
• Fifth there should be a public roadmap for LabVIEW so that we developers could estimate if LabVIEW is keeping up the pace. Now we need to live in the darkness until NI releases their next release. We have no idea if they are going to commit to one feature or another.
  
• Sixth NI should open a new forum targeted especially for professional developers. Current NI forum is used too much by beginners and is therefore useless for communicating about advanced issues. LAVA is a nice forum, but being NI external forum it doesn't reach many enough NI developers.
  
• Seventh NI should make available the source code for LabVIEW core under GPL type license (including LabVOOP but excluding hardware integration) and release advanced debugging tools so that developers wouldn't be 100% dependent of NI in fixing the bugs related to their application. Currently if there is a bug in LabVIEW source which causes our application to crash or misbehave, there is simply no workaroung. You cannot guarantee your customer that your product is 100% reliable if you don't have control over the source code of your product. NI just doesn't have good enough a track record to make us trust.
  
• Eighth there should be gold or platinum level support contracts that would guarantee that LabVIEW bugs are fixed in certain time window so that large developers would have more safety in the development process.
  
• Ninth NI should target LabVIEW to a larger audience as a general purpose programming language so that LabVIEW developers would have larger customer base for their products. It is hard to be a LabVIEW developer in a world where LabVIEW is such a small niche.
  

Our current vision is that for the time being we will use LabVIEW as it provides a fast way to develop what we are developing. We can test our concepts using LabVIEW pretty fast compared to other programming languages. However we do not see it possible for us using LabVIEW as development tool for our enterprise level application and API, because of the above mentioned problems and because of some short comings in the language itself, especially due to the difficulty of expressing by-reference data.

I very much appreciate your contribution Stephen to this forum and to LabVIEW development towards more like a professional tool. If NI as an organization would have similar target as you personally do, I wouldn't think we had a problem. But NI as an organization is not giving us much hope with it's current policy towards professional LabVIEW developers.

[pallen]

Hi,

LabVIEW 8.20 seems to have a large number of bugs that make LabVIEW either crash or freeze or corrupt the project etc.

I can't really offer any suggestions to you, as I've not even begun to look at LVOOP yet, and that appears to be part of the problem.

However, our newest programmer where I work has decided to be the first to implement 8.2 in a project. (He was actually specifically told not to do this...but did anyway) Comparatively speaking, this project is very small. It's a glorified vise with some sensors and a barcode reader. But already he has lost "all his work" several times. Many of his problems seem to be related to the State Diagram Toolkit as he's experiencing many crashes during it's use. Often these crashes leave his project corrupted and unable to open. Or when it does open, there is no visible code at all and the scroll bars on the BD window are non functional. I've never seen this in 7.1

Considering my average alloted development time is now measured in hours and days, there's no way I'd have the time to debug my DE.

Hopefully you'll find a solution in time for your project.

--

Patrick Allen

[LAVA 1.0 Content]

I reverted to my sunday backup. It seems to work fine. I repeated the work I did on monday and tuesday i.e. added one class to the project from scratch. Guess what. The project got corrupted again, exactly the same way as the last time. EDIT: I talked to the local NI support this morning. They had no ideas how to help. They could only help if I could isolate the bug. I don't know how. Without symbol tables for C++ I would need to reverse engineer machine code. Gets kind of hard. So I have a project we have been working on for three months now. It is in two separate pieces the other one of which gets corrupted when I try to work it further. Despite of the SSP contract NI cannot help. There are no patches available to LAbVIEW and as Stephen said, there is no public information when one will be available. Nobody knows if the patch will even fix the problem. I start to think of our team moving to the combination of native C++ and managed C++ sooner than I thought yesterday.

Any ideas? EDIT2: The debug output of Visual Studio debugger looks like following when I try to open my project and LabVIEW crashes:

Successfully loaded "Loading"

Missing HResource for _Loading

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Not a JPEG file: starts with 0x89 0x50

Successfully loaded untitled VI

Got a reentrant call to WForceSetFocus. Curr: [Wind (NULL) hostPort=NULL ""], to: [Wind (0x01f4da70) hostPort=0x00070896 ""]. gTrackLevel: 0, gTrackWind: [Wind (NULL) hostPort=NULL ""]

FTextToPath: NULL text passed in

Not a JPEG file: starts with 0x89 0x50

FTextToPath: NULL text passed in

Not a JPEG file: starts with 0x89 0x50

FTextToPath: NULL text passed in

FTextToPath: NULL text passed in

Not a JPEG file: starts with 0x89 0x50

FTextToPath: NULL text passed in

Not a JPEG file: starts with 0x89 0x50

FTextToPath: NULL text passed in

Not a JPEG file: starts with 0x89 0x50

clone not purgeable!! (cacheing) [VI "MyLibrary.lvlib:MyRootClass.lvclass:No Error in Array.vi:2" (0x02ada7e0)]

clone not purgeable!! (cacheing) [VI "MyLibrary.lvlib:MyChildClass.lvclass:Get Subexpressions.vi:1" (0x06b79810)]

First-chance exception at 0x00000000 in LabVIEW.exe: 0xC0000005: Access violation reading location 0x00000000.

Unhandled exception at 0x00000000 in LabVIEW.exe: 0xC0000005: Access violation reading location 0x00000000.

Another place where I see odd behaviour is whn I try to close my project after saving all. A popup appears asking me to save some unsaved VIs (although they were just saved). The debugger output during this thing is below:

Missing HResource for _ProjectWindow

gUnattended will cause VIs leaving memory during GetInstHandle to get saved automatically. This is dangerous. -nick.neumann

EventOracle::DestroyQueueObject 2

EventOracle::DestroyQueueObject 1

Successfully loaded "Save before closing?"

[Roy F]

...I've very patiently been sending bug reports to local NI support. They have then submitted bug reports to the head office. However the head office has refuced to investigate bugs that occur on large projects because "these are project dependent bugs and cannot be recreated in an empty project".

...Because of these kind of aswers, I've stopped sending my large projects that cause LabVIEW to crash to NI support as it doesn't help me nor anybody else and only causes extra work to local NI support.

...The current project contains classified information, so this time I even cannot submit the project to NI, at least not without explicit NDA which I regret they will refuse to sign.

Jimi,

It is not our policy to refuse to investigate problems in large projects. There has obviously been a misunderstanding. We need to be able to reproduce problems in order to fix them. Anything we can get from a user that helps us do that is valuable. Reducing a problem down to the smallest number of components is obviously very beneficial, but as you stated, not always possible. If you are willing to send us everything we need to duplicate a problem, we will not only accept it and investigate, we had better be appreciative of your willingness to help us.

So, I apologize if you have encountered some support situations which were not handled as well as they should have been. If you will supply the SR numbers where we refused to accept your offer to send us code that reproduces a problem, I will follow-up on our side, both to get your problem satisfactorily investigated and perhaps counsel a young support engineer.

As for the NDA, it's not something we want to do regularly, and we obviously want to push a harder to get the problem recreated in something that would not require NDA, but we will if needed. If you have encountered a problem which we can not make progress on without your code, and you feel the problem is important enough for both of our companies to have NDAs processed, then we should pursue one. We want R&D buy in before doing this. My recommendation would be to ask the AE for an escalation to a Product Support Engineer (you're within R&D at that point) with the idea being that you will need an NDA before you can send us your code. If you get pushback (e.g. disagreement on the severity of the problem), go to your DSM for help on escalating the problem.

I certainly appreciate all of the time you have spent helping us to find and fix our problems.

Roy Faltesek

Senior Group Manager

LabVIEW R&D

[PJM_labview]

Jimi,

Did you try my suggestion to uncheck allow debugging in the reentrant VI(s) that prevent your project from opening? Did it had any effect?

PJM

[LAVA 1.0 Content]

Did you try my suggestion to uncheck allow debugging in the reentrant VI(s) that prevent your project from opening? Did it had any effect?

I tried. I reverted to a working backup and then edited every VI so that allow debugging is turned off. LabVIEW crashed when I tried to save all VIs and I ended up having a corrupted project. I haven't retried it yet.

[Born2Wire]

Maybe this is a silly suggestion that you have already thought of and checked.

Could it be that there is some corrupt memory on the machine that you are developing on?

[LAVA 1.0 Content]

It is not our policy to refuse to investigate problems in large projects.

Excellent. I'll try to remove the most sensitive parts from the project. If I still after that manage to recreate the problem, I submit it to your support. I appreciate Roy that you considered my problem important enough to post your first post to this forum!

Could it be that there is some corrupt memory on the machine that you are developing on?

Thanks for the proposal. I did consider this. I tried to open the project on another computer, but it was corrupted there as well. As I don't know if the corruption is due to prior memory errors, I'm currently running memory diagnostics. Nothing found this far. EDIT: At least one 1 hour test passed. So memory problem is very unprobable.

[tibobo]

I encounter the same problems than jimi since I added LVOOP in my project (about 300 VIs) : crashes after run arrow hit, save all, open a project...

I used GOOP for a while, and chose to switch to LVOOP so as to "enjoy" NI support, full integration in the project manager window, speed, and easier learning fo engineers/students we recruited. I didn't know it would be such a crashing nightmare... I should probably choose to recode everything we did with LVOOP in GOOP. I'd prefer to see if these workarounds could save me until bug fixes is released.

Consequently :

- We want NI to know that WE NEED THIS BUG FIX SOON. A 8.21 WEB release would be good for us (even if some people would complain about mass compiling) and cost nothing to NI. I'm embarassed to say to my engineers : "yes, we use LV. I chose it. We paid xxxxx$ for it and it's not working at all.". I won't bear it for long.

- How can I do this "ctrl+shift+run arrow" stuff with my macs ? when I do "Apple+alt+run arrow" nothing executes but my vi seems to be modified since it gets an "unsaved" * mark. I thought there would be a "mass compile" pop-up ?

Boris

As angry as Jimi !