08-31-2010 02:36 PM
This problem started with a fatal error while building that gave a message about dramgr.cpp line 3570. Based on a suggestion in this thread, I changed my registry key for maximum GDI objects per process from 10,000 to 20,000. Now instead of an obvious crash with a fatal error and a message, LabVIEW appears to finish the build (the progress bar completes), but with no dialog at the end waiting for me to click Done. Looking in the build directory reveals no .exe, and LabVIEW meanwhile has crashed and needs to be terminated.
Task Manager shows LabVIEW reaching a peak memory usage of 327 MB and a maximum of about 14,500 GDI objects during the build. This leaves a comfortable space of memory and available GDI objects, so it does not seem to be a memory problem.
A couple behaviors that may also be telling:
- While building, LabVIEW pops up a dialog saying it's compiling a couple VIs, which is odd because in the past it has always done this when saving a file rather than waiting until building. There are two files it compiles mid-build, one of them a normal VI, one a .ctl which is the private data for a class.
- Early in the build, long before LabVIEW's memory footprint and GDI object count have started to climb in earnest, the screen flickers very rapidly for several seconds.
Does anybody have any idea what's going on?
08-31-2010 04:02 PM
I should have mentioned, this is with LabVIEW 8.5.1.
09-01-2010 09:26 AM - edited 09-01-2010 09:34 AM
Is it possible for you to file a CAR on this issue with your project attached and post the CAR # here?
09-01-2010 01:10 PM
Probably; what's a CAR and how do I file one?
09-02-2010 02:14 PM
Call 1-866-ASK-MYNI and you will be routed to a Customer Service Representative (CSR). You will then need to say that they want to "report a bug" and they will tell you how to send us your code. The CSR should put you through to an AE who can then get your code and reproduce the issue. Then if you post your service request number on the forums I can look up your request.
Unfortunately I don't know of any simpler way to take a look at your code. I have worked on some similar issues recently but I need to look at your code to see if it would benefit from recent fixes I have made to LV or if it is another issue causing it.
09-03-2010 12:06 PM
It built. I can still submit a bug report if you want to investigate the bug anyway; I have a backup from when the error was occurring.
GDI objects peaked just shy of 11k when it built successfully. So I still need to keep the per-process quota above its default, but whatever error was causing it to fail was also causing it to generate 2.8-3.5k extra GDI objects.
I don't know how helpful this will be for anyone who is having a similar issue, but here are the things I tried that didn't work along with what finally seemed to fix it. First, the things I tried that didn't fix it (most of which have fixed equally mysterious problems in the past):
- Opened the VI that was compiling mid-build and forced it to compile by control-clicking the Run button.
- Rebuilt the class that the .ctl file that was compiling mid-build is associated with, by copying/pasting the block diagram of each member VI into a fresh VI, adding them to a fresh class, and connecting the new class back into the class hierarchy in place of the old one, which I removed. (A lot of the problems I run into in LabVIEW seem to stem from file corruption, and are fixed by doing this sort of thing.)
- Created a new build specification from scratch.
- Created a new project file from scratch (which necessitated creating another new build specification as well).
- Simplified the implementation of the last thing I added before it stopped building properly. This reduced the number of GDI objects generated while building from 14.5k to 13.8k, but it still compiled a couple things mid-build, caused the screen to flicker a lot and then crashed.
What finally fixed it: I attempted a build, expecting it to fail but just checking to see if it was still compiling the same two files mid-build. (It wasn't, actually; rather than compiling the VI, it compiled the .ctl of the private data of the class that VI is a member of. So two .ctls instead of one .ctl and a .vi.) LabVIEW complained that it had had to resolve naming conflicts, so I opened up the build spec and found that it had lost about two-thirds of the destinations I had created and forgotten which destinations almost all the files were destined for. So I fixed all this, saved, quit, opened the project again, and it had forgotten some of the destinations again. Lather, rinse, repeat until I opened it three times in a row and it hadn't forgotten anything.
And then it built successfully--no mid-build compiles, no screen flickering.
09-03-2010 02:31 PM
I'm glad it is working for you now! I would still like to take a look at the bug if you can submit it.
09-09-2010 11:46 AM
Hey Thrutell
If you would like for us to investigate this crash and identify its source, please post your code and I will work to try to recreate the issue on my machine.
I have seen a few CARs regarding your initial issue with an error log file: drawmgr.cpp line 3570 but none with this sort of symptom/work around.
Regards
Logan H