CVI 8.5 IDE fatal errors

[Mert_A.]

In case it is an issue with the collapsible source code regions (code folding), it would be very helpful to have your source code to try to test with.  Would it be possible for you to zip up your workspace, projects, etc and post it to our ftp site (ftp.ni.com/incoming) then let us know the name?  Do you notice that it is usually the same source files active when you get crashes?  Have you tried disabling collapsible regions (near the bottom of Options>>Editor Preferences dialog) for a while to see if your crashes subside?

Thanks.

Mert A.
National Instruments

[gvan]

I have had collapsible regions turn off for the past several days and I haven't seen a crash yet.  I'm not able to post the source code for my actual projects, but I am fairly certain that the crashes happened in more than one workspace.  If I get confident that the collapsible regions turned off has solved the problem, I will turn it back on and then keep track of what workspace I was working in when the crash happened.  I've been working on four applications fairly evenly over the past month of so.  If I do find that one was the cause I will try to make a stripped down version to send.  Given that the crash was not very predicable or frequent, that process could take a while.

Greg

[menchar]

I had been using source code regions all along, but crashes have subsided to the extent that I haven't seen one in weeks now.

I've had them disabled the last few days and no change - no crashes.  Source code regions, auto backup both were enabled at the time I was seeing the crashes, and my workspace had multiple projects in it. 

One other poster early on seemed to have encountered a crash at the exact same spot I had - when I was confirming a save of a changed file before closing the project and opening / adding a new one.

Menchar

[blakney]

Sorry,

I have not been following the boards as well as I should. I have seen several crashes with 8.5.

Unfortunately, I have not tracked the crashes as they appeared to be fairly random. I have seen several crashes in 8.5 up to maybe two or three a day when building in a bunch of new features (as opposed to debugging). It would not surprise me to find that some of these crashes happen after a "generate callback" or  "view callback" .

I also see that when switching between projects that sometimes not all of the windows from the old project close down. (They may or may not be listed in the current project tree, but the panel that contains the code remains open from the last project.) 

I will try and see if figure out if this might mean that out of 15 panels that are open the first dozen close but the last 3 don't.  Not an exact count but similar to what I have seen.

I could see this causing a lock up if there are two similarly named panels "loaded" at the same time.

Mainly, I wanted to tell you that there is at least one more out there.

Greg

[menchar]

Now that blakney mentions it, I would say that I too have been mystified at times over the files that are open when startng up the IDE.  It often seems to me that some files are getting "resurrected" on IDE startup long after some previously loaded project's been closed.  And I certainly have seen the crashes when projects are being loaded / unloaded.

Menchar

[LuisG]

Hi Greg,

Allow me to clarify what the policy is for managing files in CVI.

1. It is the workspace that maintains the information of which files are and aren't open, not the project. So if you have multiple projects in a workspace and you switch projects within a workspace, that has no impact on the list of open files.

2. A workspace remembers which files are open. When you unload a workspace (whether it is by exiting CVI, by creating a new workspace, or by switching to a different workspace) and you then re-load the original workspace, CVI will re-open all the files that were open at the time that that you unloaded the original workspace.

3. After you unload a workspace, CVI will remove all files that did not belong to any project of that workspace. Let's say that while you are working on workspace 1, you open project files A, B, and C, and you also open non-project files U and V. Now, let's say that you switch to workspace 2. CVI will close A, B and C, but will leave files U and V open (since they're considered neutral files, not necessarily belonging to workspace 1). When you open workspace 2, CVI will open the files that were last open when workspace 2 was used, and will keep open files U and V.

The implication of this last paragraph is that non-project files remain open across workspace switches. What this means in practice is that they will accumulate and never be unloaded unless you explicitly close them. This is by design, and reflects the policy that CVI has always had, going back to version 3.0, when there were only projects and no workspaces. Back then, after you'd switch to a different project, CVI would close only the files that belonged to the project you were switching from.

These are the rules, but the crashes are a different story. If you can reproduce some of these crashes you've been seeing, I'd be very interested in finding out more about it, so that we can investigate them. At least having the crash address might help some. Also, if you can reproduce some file management behavior that does not conform to the rules I described here, I'd like to know about that too.

Thanks,

Luis

[blakney]

Thanks for the clarification Luis,

I should note that I really like two of the new features: 1) collapsible code areas and 2) mid-debug code edit.

I am aware of the "neutral file" rule at least in the case(s) where you double-click on a random c file and it is opened along with the last project files . This random file then resides with the project until manual file close or CVI is closed. The scenario I have seen in CVI 8.5 is that a file resident to project 1 does not close when you switch to project 2. (Sidenote:The extra files does not get added to the project either.) It seems that while several files from project 1 close but not all of the files do. Then new project opens and starts popping open the files from project 2 that were left open from the previous instance of project 2.

I don't know that this is contributes to a possible later crash because I now pseudo - consciously take note when the "extra" files are open and close them. Note : I don't remember a crash on switching project but when I am programmatically adding  or looking up a callback from an UIR file as mentioned above vaguely seems to ring a bell. I have seen less and less  crashes but I will note the error message from the next one.

I can't say that this IS or IS NOTcausing a crash - the crashes are still somewhat random. I can say that the new workspace reacts differently than CVI 5, 5.5, 6, 7.1 or or even 8 - but this occurs somewhere between "occasionally" and "rarely".  I was just thinking that this new behavior might be related to the original topic?

Greg

[LuisG]

HI Greg,

Assuming that your project 1 and project 2 are not in the same workspace, then those files definitely should be unloaded when you switch projects (this should also apply to header files included in any project file, as long as the project was compiled while it was loaded). If you're experiencing something different, and you can reproduce it, then I would be very interested in investigating this, although that might require you to zip up the workspace and send it to us. I just tried it again with a couple of our workspaces, and I couldn't reproduce that behavior.

This code wasn't really modified for CVI 8.5, so it's definitely odd that you only started seeing it with 8.5. Is it possible that it might have been happening in older versions as well, but became more noticeable in 8.5, since the tabbed workspace makes the list of open files more visible?

I don't know whether or not this could be a cause for the crashes reported in this thread. Since this is unexpected behavior, it certainly has the potential to cause a crash down the road -- we can't rule it out. But since we don't know the root cause of the problems reported in this thread yet (other than gvan's collapsible region problem) we also can't rule it in.

Luis

[blakney]

OK, Luis.

I think I have it.

Open work space A - now open a neutral file "NF". Now switch to work space B. NF is still open. Close NF. NF goes away. Now switch to work space A and NF "returns".

Similarly, Open work space A - now open a neutral file "NF". Now switch to work space B. NF is still open. Close NF. NF goes away. Close CVI. Open CVI. Defaults to workspace B - no NF. Switch to workspace A and NF returns.

It appears that the NF becomes associated with work space A until workspace A is open/active while NF is closed.

It may be that this is "normal" and possibly even the way it has always been but it just feels different to me.

I hope this helps one way or another.

Greg

[LuisG]

Hi Greg,

Actually, the behavior you're describing is normal and expected.

Once you open any file in workspace A, that file remains associated with workspace A until you close it while workspace A is loaded. I'm pretty sure this behavior has always existed, going back to the beginning of CVI (and substituting projects for workspaces).

The reason NF is closed when you switch to workspace B is so that NF doesn't also become associated with workspace B. It is this aspect that I was focusing on in the previous post. I was only considering what remains open in a new workspace when you switch to it from the previous workspace.

Luis