LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

CVI 8.5 IDE fatal errors

Uh-ho. A co-worker just pointed out a mistake I made in the last paragraph.

I wrote:

"The reason NF is closed when you switch to workspace B is so that NF doesn't also become associated with workspace B."

I meant to say:

"The reason non-NF files are closed when you switch to workspace B is so that they don't also become associated with workspace B."

Sorry about that.

Luis

 

0 Kudos
Message 41 of 64
(2,518 Views)

Thanks, Luis.

I understand the philosophy but I have this little voice that tells me there is a new behavior in there somewhere. Maybe I have just been running on too little sleep.

Now i am going to switch back to the primary part of the original thread - I had an IDE crash this afternoon. I tracked it as best I could.

CVi 8.5 - debug mode - collapsible regions turned on if it matters.

History - Debugging / adding functions for three hours or so (unfortunately way too many actions to track).

I will pick up where the action happens.

I had to tweak a main header file which marked 90%+ of the project for recompile.

I recompile the project (warning: I may use workspace and project interchangably- I only keep a single project per ws) with errors - errors were expected so no worries yet.

Open uir file.

Right click control and choose View callback.

Immediately (compiler did not search through available c files) pops up CVI message - No valid source code files are loaded - sorry for the paraphrase but actual message was similar. At this time I begin to expect a pending crash.

Expecting the crash I go ahaead and save all files. Come back to same uir. Try view callback and same CVI message - "no valid c files".

Go to some open c code panel debug a view things maybe edit five lines of code. Save.

Swicth back to uir and try view callback.

Machine unresponsive for maybe five seconds (long time for this computer unless compiling whole project) then CVI message : Unrecoverable Internal Error at 001B:10064822. Labwindows/ CVI will be aborted.

I click OK

CVI Message : Panel, Popup, or menubar handle is invalid . Click OK

(This message plus the click on OK will now be reffered to as "Q" and mulitples as 2Q where Q happened twice )

2Q

Current uir closes.

Another uir becomes active panel.

4Q

Second uir closes C panel becomes active.

5Q

C panel closes

8Q

All files are now closed. Project Tree? closes (ws panel in upper left where project/ws files are visible)

Q

CVI environment closes.

On reload everything seems normal with 5 panels open (the same panels that were open at crash - as best I can tell). Opened the problem uir right click the same control and do view callback. Compiler thinks normal amount of time (less than a second) and open c code to correct location.

The probelm is that I can not find the initial conditions to trigger the original cvi message - no valid c files.

Hope this helps,

Greg

0 Kudos
Message 42 of 64
(2,501 Views)

Hi Greg,

Thanks for the really detailed step-by-step description. The memory address that you provided and the description of the steps you took both help narrow down the problem a great deal. While we still haven't found the underlying problem, this does give us some additional clues that we didn't have before. And it reinforces the notion that, although the root cause of the problem seems to be elsewhere, the crash point oftentimes is when CVI looks for a callback view or generate -- as had been reported by gvan previously.

At this point, my only question is whether or not you are using collapsible regions, since we've found a problem when using collapsible regions that might be the cause for this.

Thanks,

Luis

0 Kudos
Message 43 of 64
(2,467 Views)
I have not specifically disabled collapsible regions and as such they are available to collapse.  Also, I do not think that I had any code region "collapsed" at the time of the crash - but I am not positive.  I am not sure which instance of "use" that you refer, so I decided to answer with too much information.
 
Greg
0 Kudos
Message 44 of 64
(2,462 Views)
I meant enable/disable. Thanks!
 
Luis
0 Kudos
Message 45 of 64
(2,461 Views)

Another question about "normal" operation and to see if this could signal a problem.

 

When you do a search for multiple files, you will get hits from the the new unsaved and the temp verisons of the files (fileio~xxxx.c and fileio.c). If you click on the search result in the temp file, it opens. Now if you switch worksapce the original is saved (at prompt) but the temp file remains in the new environment.

Does this temp file exist after you "save on exit" from the old workspace or does the autosave erase the file but not close the handles to it? Could this explain the View Callback triggered crash?

Should temp files be searched when you button click search all.c files?

I did not continue on beyond that to squeeze out a crash but I am wondering if there is check or balance awry here.

Still trying, Greg

0 Kudos
Message 46 of 64
(2,430 Views)
Hi Greg,
 
Unfortunately, the behavior that you describe is expected, and does not explain the crash.
 
Yes, it is expected that when searching an entire directory, the temporary (auto-backup) files are also included in the search. We've already received some feedback that this is undesirable, and we might be tweaking this behavior in a future release. It's not an obvious call, since there are circumstances in which someone might want to include these files in a search. But in most cases, one wouldn't want to. So we'll try to be smarter about when to include them in the search.
 
In the scenario that you describe, when you unload the previous workspace, CVI tries to close the files that belonged to a project (as addressed in the earlier post). The temp file, on the other hand, stays open since it is not part of the project (this too is debatable, to some extent). Whenever you save the original file, regardless of the circumstances, the temp file is intentionally deleted from disk. The fact that it is also opened in CVI at the time is not important. Note that, at any time, once can go outside of CVI and delete a file that is open in CVI. This should not put CVI in a bad state. And this case is no different. Even though it is CVI itself that is deleting the file, it's perfectly okay for that file to remain open in the editor. You can then close it yourself, or restore it by saving it.
 
Thanks for continuing to try!
 
Luis
0 Kudos
Message 47 of 64
(2,420 Views)

It has been a while, but I've got a new CVI crash..

Action: quickly closing open files in the tabbed environment.  The exception seems to have been raised when I got to a file that needed saving, but before I was prompted to save it;  It was the active tab when the exception was raised.

First the message "a custom control has raised an exception"

address: 001B:100B50C7

Then dozens of "Panel, popup or menubar is invalid" messages.

Eventually I get a save file dialog, but for "untitled1.h", which I don't think was an open or new file before the crash and wasn't the highlighted tab when the first expection message appeared.  It contained the prototype header file.

I continued to get dozens of "Panel, popup or menubar is invalid" messages, that did eventually stop... until I click anything.. dozens more... etc.etc. ad infinitum.

When I right-clicked the application in the task bar (to try and close it), it's popup menu contained no text.  (looked to be the right height and had the icons  but no text.  It was only slightly wided then the icons and they didn't work)

Greg

 



Message Edited by gvan on 04-08-2008 08:20 AM
0 Kudos
Message 48 of 64
(2,314 Views)

Thanks, Greg.

This seems to be a different issue from the one you were having earlier. I'm still assuming that your earlier issue was related to collapsible regions, given that it hasn't happened again after you disabled them. We did fix a problem related to collapsible regions that might be the problem you were having -- although we were never able to reproduce your problem in quite the same way.

As for this new crash, I checked the address but it didn't help narrow down the problem. I also tried performing the actions that you describe, but it didn't crash. The only thing that will help is reproducibility. I don't suppose you were able to make it happen a second time, were you? If you do see it happen again, please do let us know. It was your repeated descriptions of the previous crash, and tying it to the action of viewing/generating a callback, that helped us find the collapsible region problem.

Thanks!

- Luis

0 Kudos
Message 49 of 64
(2,291 Views)
gvan is seeing this error in the same area that I orginally posted - seems there's an error associated with saving a file when unloading / loading a project.

Menchar
0 Kudos
Message 50 of 64
(2,288 Views)