Application causes vi analyzer to crash

[wideofthemark]

I'm having some problems with my application. 

Basically it causes labview variously to 'hang' and sometimes to just pack up and die.  It used to be more stable before i upgraded to lv2011, although i'm not 100 percent sure that the instability comes from the upgrade or from new coding - i've been trying to change some of the interface to use producer\consumer loops with data being passed between front panels in loops - so there is possibility of memory leaks i guess - although i would have imagined that these would have caused memory errors - rather than flat out crashes. 

Since then at least once i had a VI get corrupted so that the project was un-openable.  I managed to delete the vi that got borked and it was then openable.

I have been doing my best to try to find bugs\memory leaks in the code using the trace tool, and then just now I tried using the vi analyzer tool to check the code.  Rather worryingly this seems to 'crash' before it can complete. 

I'm a bit worried that something in my project is corrupted as before - but a little unsure how to find it.  Does anyone have any advice?

JP

[wideofthemark]

Ok... So here is something weird that appears to be happening in the project.  It seems like it is trying to use 'directories' as vis.  -  ie there are some directories that are comming up in the files view of the project with a vi icon. They also come up in the dependencies in the items view.  See below - the 'c' drive has become a vi!

I removed all but one of the affected vi libraries which is attached - if someone can explain the weird behaviour.

I'm not 100% sure that this is causing the crash - for example i tried putting it through the Vi analyser, and it didn't crash like it did on the full project.

[JTG_Wilson]

Hi JP,

When I open your project it doesn't show any of the errors taht you are seeing.

Does this still happen if you create a new project and add your VIs to that?

[wideofthemark]

Sorry everyone, I got some help direct NI as well - emails quoted below - in case it happens to someone else.

Basically I'm now at a situation where the dependency issue is fixed - using the work around below.  Also I can 'save to' a zip file - which fixes one of my other problems.  I also managed to solve my memory issues - I hadn't understood queues properly.

I still am having isues with the VI analyzer - it is crashing - but it seems now that it is giviing some sense in the log - it seems to be complaining about a FPGA VI i have.

Hi John,

My name is Peter and I am one of the Applications Engineers for National Instruments in the UK and Ireland.  Thank you for you message pertaining to several crashes in the LabVIEW project environment.  We have set up service request #7344719 for this issue.  Please quote this reference when getting in touch by telephone on 01635 523 545, alternatively you can reply directly to this email message.

I have been able to replicate your issue using the "TEST" project you uploaded to the forum.  This is an unusual issue which we have not experienced previously - the root cause appears to be corruption in the Menu_Details VI.  The dependancies list the user directory, which should never be the case.

In order to work around this issue I recommend copying the code from the corrupted VI into a new VI of the same name within the project.  Doing this with the Menu_Details 'refreshes the dependancies to what we would expect.

If you are able to let me know a circumstance where we can consistently experience corruption then I will report this as an issue requiring corrective action.

Best regards,

Peter Duncan
National Instruments
Applications Engineering
www.ni.com/support

------------------------------------------------------------------------------------------

Thanks for the advice,

I have done what you said and the dependency has gone now.  I'm not exactly sure if i can provide a situation where it would happen again - basically i've been having quite a few issues with my project recently, some of which are likely to be bad programming on my part - but some which i think are due to some corrupted files. I had a particularly bad incident the other week when one of the files got completely messed up, and the project wouldn't load until i deleted it.

I'd be grateful if you could try to help me iron out these problems - would you be able to identify whether there are corrupted files in the project hierarchy if i sent you the whole project?  I don't expect you to hoke through the whole code, but if you could at least check out if there are any vis that are corrupted that would be nice. 

** BTW - there are some Vis that are 'broken' - either legacy code that i need to delete or stuff that I need to update - i don't need you to fix the code, but like i say if you could check whether the project as a whole doesn't have any nasty corrupted vis in it - that would be very helpful.  There are a few other issues with my code that cause hangs and sometimes crashes - but i am pretty sure they are due to bad programming on my part - mostly to do with FPGA references, and queues.

Symptoms that worry me:

1
I'm not able to 'save' a project to a new directory - I used to do this when i was about to do a lot of development work - and after, since for one thing it gave me a clean copy to fall back on if i messed things up, and secondly it got rid of any unused vis that i created and then dropped out of the project file. This has been happening for a little while now.  Originally i thought it was something to do with using 'run time menu files' - since it would copy the run time menu, but nothing else - or because of the directory length - i have some libraries from hardware people, and they have a very long directory tree.  I've been working around it by copying the whole project to a new directory (1), then copying the project file to a different directory (2).  Then closing and opening up the project from directory 2, and dragging all the folders from one directory to the other in labview.   I guess though this might be a symptom of something corrupted.

2
I figured i would try to work out if there were corrupted files by doing mass compiles - and more recently when i installed the new labview the vi analyser.  The vi analyzer seems to crash when running through the project - which i guess isn't a good sign.  The mass compile also crashed when i was having the most problems - although it seems to be able to run through now.



JP

----------------------------------------------------------------------------------------------

Hi John,

Sorry to hear you are still having issues with this project.

The steps which you have completed are exactly the same as what I would undertake to check for corruption - mass compiling.  If this is able to complete then that suggests that the VIs are not corrupted - although the 'strange behaviour' does suggest something at bay.

To highlight a few points with regard to your concerns:

-  Saving the Project to a New Directory

When you attempt to do this, what is the result?  You mention that it fails however are there any error messages displayed?  I would try creating a build specification to create a zipped folder of all of the project files - right-click Build Specifications » New » Zip File.

Try doing this and, if successful, use the newly zipped project as your base.  Following this I would create a new project and transfer files across or copy block diagrams as we have done with the previous VIs.

Best regards,

Peter Duncan
National Instruments
Applications Engineering
www.ni.com/support

----------------------------------------------------------------------------------------------

[Pete.Dunc]

Glad to hear it

[wideofthemark]

Hi,

Here is the FPGA Sub Project that seems to cause the VI analyzer to crash.

JP

[wideofthemark]

At one point it gave this error in the crash log :

DWarn 0x4218853E: Cluster content rect is not inside its frame in [VI "FPGA_Personality_Main_(U16x8Counters).vi" (0x1fb7e2b8)]
e:\builds\penguin\labview\branches\2011\dev\source\editor\osupport.cpp(3237) : DWarn: Cluster content rect is not inside its frame in [VI "FPGA_Personality_Main_(U16x8Counters).vi" (0x1fb7e2b8)]

(Along with a lot of other stuff.)

Not quite sure what it means. The Vi itself seems to run ok. - Although i guess I was having some problems some time previously with FGPA vis where FPGA VI got broken - it seemed like controls where being pushed out of the known boundaries of the block diagram - perhaps this is the same thing again.

JP

[Darren]

To get more details about when errors or crashes occur during a VI Analyzer session, there is an INI token you can set to enable logging.  I just posted this nugget with more information.

[wideofthemark]

Thanks for the tip i have been pretty busy so didn't get to test it out till today.

I found the culprit using the logging option - and I played around a bit to try to see what was causing the crash but I can't make sense of why it would cause a crash.  Basically it seems like the write to FIFO method causes it to crash.  I don't want to be to hasty but i have a feeling that it's a bug. 

It seems like the issue is that writing to a Target to Host FIFO breaks it.  It isn't a corrupted VI as far as i can see - since I created a new VI for it.  Interestingly if the 'vi' in question isn't runable - because of another error in it then the VI analyzer doesn't crash.

See the example project attached.

JP

[Darren · Accepted solution]

This crash is occurring due to a bug in an internal method used by the Parallelizable Loops test in the VI Analyzer Toolkit. We already have CAR 339315 on the issue, and it is currently slated to be fixed in the next LabVIEW release.

For now, I suggest you disable the Parallelizable Loops test for any VIs you are analyzing under an FPGA target, as any VI with a FIFO method call on its diagram could potentially cause this crash if the Parallelizable Loops test runs on it.