Jump to content

Huge number of "Insane objects" when trying to mass compile a directory.


Recommended Posts

Recently, something in our project has become corrupted such that trying to build an executable leads to a catastrophic LabVIEW crash. LabVIEW reports no errors in development mode and everything runs fine in development.

 

We've tried a huge number of fixes with no luck. Upgrading to 2013, upgrading to the f2 patch, loading the manual fix from this thread, disabling large swaths of block diagrams, removing XControls and replacing them with classes, resetting the class hierarchies of suspected offenders, deleting the object cache, tracking down all disable structures with missing VIs and removing them, etc.

 

We're on the verge of stepping back through our source control to find the last working build, but as it's been a long while since we last made an executable, we're likely to lose a ton of work and have to painstakingly add features back in one at a time.

 

Trying to mass compile our code also leads to a catastrophic crash. I started mass compiling individual subfolders and removing any warnings. This is painstakingly slow and frustrating.

 

I was finally able to mass compile one of the larger subfolders, containing a good chunk (maybe a fifth) of the total functionality. Before this, trying to mass-compile that folder would crash the LabVIEW environment.

 

But though it didn't crash, the mass compile returned a very large list of "insane objects." It also suggested that the mass compile was terminated early by me, but I had left the machine to run over lunch and the termination was NOT user-initiated.

 

I found this thread at NI Forums and may start playing around with removing the insane objects, but there are so many... anyone have any other suggestions?

 

Here's the mass compile info:

 

#### Starting Mass Compile: Fri, Feb 21, 2014 11:58:27 AM
  Directory: "C:RepositoryV12000LabviewDialogs"
Insane object at FPHP+38C8E3D0, UID 3903, in "V12000 Utility Suite Config File LV2.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOFunctional GlobalsV12000 Utility Suite Config File LV2.vi
Insane object at FPHP+222DFAC0, UID 4738, in "Settings Interface Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface Cluster.ctl
Insane object at FPHP+CE6BC20, UID 512, in "Supported Mode Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeCustom ControlsNon-GUIClustersSupported Mode Cluster.ctl
Insane object at FPHP+41DAFE80, UID 779, in "Convert Setting ID To Scale.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Scale.vi
Insane object at FPHP+41DA17B0, UID 920, in "Convert Setting ID To Data Type.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Data Type.vi
Insane object at FPHP+423F4660, UID 1386, in "Convert Array of Setting and Setting Value Clusters to U8 Array.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeData ManipulationConvert Array of Setting and Setting Value Clusters to U8 Array.vi
Insane object at FPHP+41F704D8, UID 893, in "Check Mode Initialization.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsCheck Mode Initialization.vi
Insane object at FPHP+2D157018, UID 1074, in "Settings LV2 Local Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings LV2 Local Cluster.ctl
Insane object at FPHP+123797A8, UID 2393, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+1249DFD8, UID 2324, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface LV2 Cluster.ctl
Insane object at FPHP+143ED200, UID 10245, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+230F3680, UID 11243, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceFunctional GlobalsSettings Interface_LV2.vi
Insane object at FPHP+3E2D89C0, UID 1532, in "V12000 Utility Suite Config File Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOCustom ControlsV12000 Utility Suite Config File Cluster.ctl
Insane object at FPHP+1C3F6E38, UID 2870, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+180F8BC0, UID 4692, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOSupport VIsRead Config File.vi
Insane object at FPHP+423BFE80, UID 310, in "_Configuration Module (Parent).lvlib:Cluster - Task VUS Data.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentCluster - Task VUS Data.ctl
Insane object at FPHP+34C89258, UID 427, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+313BFD60, UID 1667, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core Data - ParentLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+36A83358, UID 427, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+2CBD3328, UID 1667, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - DAQLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+3BBF6AA0, UID 427, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+39C35690, UID 1667, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Source ConfigLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+3B73F880, UID 427, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+3BEA7358, UID 1667, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Vent ConnectLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+3C811F70, UID 427, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+3C815070, UID 1667, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Validyne CalLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+3ECB3F28, UID 427, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+3ECB6E50, UID 1667, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - CustomLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+3EA17A40, UID 427, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+3EC41E70, UID 1667, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - VSALoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+4BC915D0, UID 2704, in "_Configuration Module (Parent).lvlib:Config Module Parent.lvclass:Return VUS Config Data from Module Array.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentReturn VUS Config Data from Module Array.vi
CompileFile: skipping C:RepositoryV12000LabviewDemosConfig Dialog DemoConfig Dialog Error Demo.vi
Insane object at FPHP+44085928, UID 310, in "_Configuration Module (Parent).lvlib:Cluster - Task VUS Data.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentCluster - Task VUS Data.ctl
Insane object at FPHP+4E764318, UID 512, in "Supported Mode Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeCustom ControlsNon-GUIClustersSupported Mode Cluster.ctl
Insane object at FPHP+4F7FD380, UID 4738, in "Settings Interface Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface Cluster.ctl
Insane object at FPHP+4E79A040, UID 1074, in "Settings LV2 Local Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings LV2 Local Cluster.ctl
Insane object at FPHP+4F826B48, UID 2393, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4F813440, UID 2324, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface LV2 Cluster.ctl
Insane object at FPHP+4F6F6C68, UID 779, in "Convert Setting ID To Scale.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Scale.vi
Insane object at FPHP+4F712698, UID 920, in "Convert Setting ID To Data Type.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Data Type.vi
Insane object at FPHP+4F70CD78, UID 893, in "Check Mode Initialization.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsCheck Mode Initialization.vi
Insane object at FPHP+4F76CD80, UID 1386, in "Convert Array of Setting and Setting Value Clusters to U8 Array.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeData ManipulationConvert Array of Setting and Setting Value Clusters to U8 Array.vi
Insane object at FPHP+4E7E26A0, UID 1532, in "V12000 Utility Suite Config File Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOCustom ControlsV12000 Utility Suite Config File Cluster.ctl
Insane object at FPHP+4E87E4F8, UID 2870, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4E858388, UID 4692, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOSupport VIsRead Config File.vi
Insane object at FPHP+4E665268, UID 3903, in "V12000 Utility Suite Config File LV2.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOFunctional GlobalsV12000 Utility Suite Config File LV2.vi
Insane object at FPHP+4F5458E0, UID 10245, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4F4F0FC0, UID 11243, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceFunctional GlobalsSettings Interface_LV2.vi
Insane object at FPHP+37923628, UID 427, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+440AD550, UID 1667, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core Data - ParentLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+46057E20, UID 427, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+46043AE8, UID 1667, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - DAQLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+46EA4990, UID 427, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+46EEC480, UID 1667, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Source ConfigLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+4B8DECC0, UID 427, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4B8B8088, UID 1667, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Vent ConnectLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+4C006C60, UID 427, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4BFD3AA8, UID 1667, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - CustomLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+4C2AEB48, UID 427, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4C41C480, UID 1667, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - VSALoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+54840EF0, UID 427, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+548CC480, UID 1667, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Validyne CalLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+4F76CD80, UID 1386, in "Convert Array of Setting and Setting Value Clusters to U8 Array.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeData ManipulationConvert Array of Setting and Setting Value Clusters to U8 Array.vi
Insane object at FPHP+4E7E26A0, UID 1532, in "V12000 Utility Suite Config File Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOCustom ControlsV12000 Utility Suite Config File Cluster.ctl
Insane object at FPHP+4F826B48, UID 2393, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4F813440, UID 2324, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface LV2 Cluster.ctl
Insane object at FPHP+4F70CD78, UID 893, in "Check Mode Initialization.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsCheck Mode Initialization.vi
Insane object at FPHP+4F5458E0, UID 10245, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4F4F0FC0, UID 11243, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceFunctional GlobalsSettings Interface_LV2.vi
Insane object at FPHP+4F7FD380, UID 4738, in "Settings Interface Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface Cluster.ctl
Insane object at FPHP+4E79A040, UID 1074, in "Settings LV2 Local Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings LV2 Local Cluster.ctl
Insane object at FPHP+4BDC5698, UID 2704, in "_Configuration Module (Parent).lvlib:Config Module Parent.lvclass:Return VUS Config Data from Module Array.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentReturn VUS Config Data from Module Array.vi
Insane object at FPHP+4BDC5698, UID 2704, in "_Configuration Module (Parent).lvlib:Config Module Parent.lvclass:Return VUS Config Data from Module Array.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentReturn VUS Config Data from Module Array.vi
Insane object at FPHP+4F712698, UID 920, in "Convert Setting ID To Data Type.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Data Type.vi
Insane object at FPHP+4E764318, UID 512, in "Supported Mode Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeCustom ControlsNon-GUIClustersSupported Mode Cluster.ctl
Insane object at FPHP+37923628, UID 427, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+440AD550, UID 1667, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core Data - ParentLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+46057E20, UID 427, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+46043AE8, UID 1667, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - DAQLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+46EA4990, UID 427, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+46EEC480, UID 1667, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Source ConfigLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+4B8DECC0, UID 427, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4B8B8088, UID 1667, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Vent ConnectLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+4C006C60, UID 427, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4BFD3AA8, UID 1667, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - CustomLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+4C2AEB48, UID 427, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4C41C480, UID 1667, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - VSALoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+54840EF0, UID 427, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+548CC480, UID 1667, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Validyne CalLoad Module Data into VUS Task Cluster.vi
Insane object at FPHP+44085928, UID 310, in "_Configuration Module (Parent).lvlib:Cluster - Task VUS Data.ctl": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentCluster - Task VUS Data.ctl
Insane object at FPHP+4E87E4F8, UID 2870, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )
Insane object at FPHP+4E858388, UID 4692, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOSupport VIsRead Config File.vi
Insane object at FPHP+4E665268, UID 3903, in "V12000 Utility Suite Config File LV2.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOFunctional GlobalsV12000 Utility Suite Config File LV2.vi
Insane object at FPHP+4F6F6C68, UID 779, in "Convert Setting ID To Scale.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Scale.vi
CompileFile: user cancelled at C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesTest Case ConfigurationTest Case Configuration.lvproj
CompileFile: user cancelled at C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesTest Case Configuration SubmodulesVentilator Settings ConfigurationVentilator Settings Configuration MessagesReceive Ventilator Settings MsgDo.vi
Mass compile terminated early
#### Finished Mass Compile: Fri, Feb 21, 2014 1:44:00 PM
 
 
Link to comment

A few questions:

  • Was the source code originally created in LV2013, or a previous version of LabVIEW?
  • Do you have strictly-typed VI references that contain LVOOP objects on the connector pane anywhere in your code?
  • Is the crash intermittent?
  • Is the crash reproducible in all environments? (e.g., coworker's computers, other versions of LV)
  • Are you using .NET callbacks anywhere?
  • What additional libraries (NI and third party) do you have installed?
  • Is dev environment in a VM or on bare metal?
  • If you run some other CPU taxing process in parallel on the same machine (in order to deliberately steal resources from LV), does the crash still occur?
  • Have you tried removing mutation histories from all LVClasses?
  • If you open all offending VIs, then CTRL+A on the block diagram to select everything, then delete, then CTRL+Z to undo, does the problem still occur?
  • Have you tried DETT in the offending context?
  • Have you tried Procmon filtering on LabVIEW.exe events?

Your issue sounds eerily similar to an issue that I'm incredibly motivated to put to rest myself, riddled with red herrings.

  • Like 1
Link to comment

Hey Jack, I'll answer your questions best I can.

 

  • Was the source code originally created in LV2013, or a previous version of LabVIEW?
It was originally LV2012. The build problems first manifested in 2012. I upgraded my machine to 2013 to try to fix the problem, which it didn't.
 
My coworker is continuing to try to fix the problem in 2012. It's reproducible on both our machines, though the behavior is sometimes subtly different. For example, my crash might be totally catastrophic with no error popping up. His crash might lead to a failed build and an error returning, but not an entire crash of the LabVIEW environment.
 
If he has time, he might drop in the thread and describe what he's seeing in 2012.
  • Do you have strictly-typed VI references that contain LVOOP objects on the connector pane anywhere in your code?

I don't believe this is the case. As far as I know, we only use strict typedefs for a handful of specialized GUI cases. Other cases are standard typedefs. In none of those situations are we using an object for any of our UI effects.

 

It's possible something to switched to a strict typedef by accident, but I don't have a good way of checking this quickly in such a large project.

 

  • Is the crash intermittent?
Crash happens every time I try a build.
 
  • Is the crash reproducible in all environments? (e.g., coworker's computers, other versions of LV)

It's happened in 2012 and 2013 so far. I think we've only tried it on our two machines. Mine is a Macbook running Windows 7 on Parallels. My coworker's computer is a PC laptop running Windows 7.

 

  • Are you using .NET callbacks anywhere?
I don't BELIEVE so. I'll double-check. None of the code we wrote using a .NET callback but I suppose it's possible one of the drivers or extensions we're using might.
 
  • What additional libraries (NI and third party) do you have installed?

JKI State Machine, JKI RSC Toolkits Palette, OpenG (all libraries included in the standard package), the Debug branch of Actor Framework, the Missing Systems Controls UI suite, 

 

  • Is dev environment in a VM or on bare metal?
Mine is a virtual machine on a Mac; my coworker is running Windows on a PC machine.
 
  • If you run some other CPU taxing process in parallel on the same machine (in order to deliberately steal resources from LV), does the crash still occur?

I haven't tried it. I have a build attempt running right now, I'll give it a shot after. If I switch LabVIEW over to a single CPU in Task Manager, would that be sufficient?

 

  • Have you tried removing mutation histories from all LVClasses?
Not yet. I'll add that to the list of things to try.
  • If you open all offending VIs, then CTRL+A on the block diagram to select everything, then delete, then CTRL+Z to undo, does the problem still occur?

The sheer number of VIs that returned "Insane Object" errors makes me loathe to try this. I suppose I can try it with one or two VIs on the list and see if they still return an "Insane Object" error on re-compile.

 

  • Have you tried DETT in the offending context?
I've never run DETT during a build attempt and didn't realize that was a potential debugging option. I can add that to the list of things to try.
 
  • Have you tried Procmon filtering on LabVIEW.exe events?

Had to Google this. Never used Process Monitor before. Is it pretty intuitive or is there something I need to know before trying to watch the build? I'm guessing there's some logging option.

Link to comment

"It was originally LV2012. The build problems first manifested in 2012. I upgraded my machine to 2013 to try to fix the problem, which it didn't." << Aha.

 

"we only use strict typedefs for a handful of specialized GUI cases. Other cases are standard typedefs" << Not strict typedefs -- do you have any strictly-typed VI references (with an LVOOP object on its conpane) statically linked to any code in your project?

 

"The sheer number of VIs that returned "Insane Object" errors makes me loathe to try this. I suppose I can try it with one or two VIs on the list and see if they still return an "Insane Object" error on re-compile." << I feel the pain, but give it a go. If this unintuitive workaround of deleting then undoing that deletion "fixes" your root prob, we're almost certainly seeing a related issue.

 

If the above "workaround" seems to (temporarily) fix your issue, in the context of your other answers that's enough to take this offline to compare notes, then report back here on results.

 

One final question -- is it possible you may have refactored data structures by changing owning library of a typedef'd cluster?

Link to comment

Not strict typedefs -- do you have any strictly-typed VI references (with an LVOOP object on its conpane) statically linked to any code in your project?

 

Ah, I see. The answer is no.

 

I feel the pain, but give it a go. If this unintuitive workaround of deleting then undoing that deletion "fixes" your root prob, we're almost certainly seeing a related issue.

 

Right now I'm moving all the classes in and out of libraries to reset the mutation histories. If that doesn't work then I'll try the delete block diagram / undo thing next. By the way, is there a more efficient way to delete class mutation histories?

 

One final question -- is it possible you may have refactored data structures by changing owning library of a typedef'd cluster?

 

Well, that's definitely happened now that I'm removing mutation histories by the dropping in/out of libraries. This also happened on occasion in the past when we'd move a class (and any associated cluster typedefs) into a new library. What's the danger of that type of operation? I would imagine this happens regularly to many programmers who use both libraries and typedefs, which is a category I think most people using Actor Framework would fall into.

Link to comment

Hey guys, I'm Mike's state-side coworker, Tom.

I have tried resetting the mutation history of every class in our depot via two methods:

  • [*]The Set Mutation History.vi in vi.libutilityeditlvlibslvclass.
      [*]A custom script that deletes everything between the tags and (including the tags).

After resetting the mutation history (both ways) I am able to build an executable, but the error "VI has an error of type 102208. The full development version of LabVIEW is required to fix the errors." in thrown as soon as I run the executable.

Edited by Tom Fantasia
Link to comment
One final question -- is it possible you may have refactored data structures by changing owning library of a typedef'd cluster?

 

We recently moved about 20 classes out of a library.  These were mostly abstract classes, but one might have contained a typedef, but I don't think that any contain a typdef'd cluster.  

 

After resetting the mutation history for all classes as described in my previous post, a single typedef claimed to have unapplied changes.  It did contain an event reference.  That may be just another red herring, but I figured it worth mentioning.

Link to comment

Thanks for the feedback. Since you're now able to build, this could mean one of two things: your corruption is resolved, or it's dormant. (Runtime error 102208 would tend to indicate that your Run-Time Engine is not fully installed on the deployment machine you're testing the distro on -- my hunch is this might be unrelated altogether to the original issue)

 

Errors/corruptions like this are nearly always solvable within a single targeted debug session, with some combination of mass compile, clear object cache, clear mutation histories, inspect linker info for anomalies, procmon or DETT, clues from the crashdump, or at least narrow down to single simple repro and ask for the CAR and refactor to avoid that issue. Inconvenient, but certainly no big deal or more than a half hour. This particular corruption issue (on my side, at least) has had me baffled for over a month, and has manifested itself as several disjoint bad behaviors on end-user's machines, and intermittently. Sometimes, the application runs for weeks, then one day crashes to desktop every time the application is launched. Sometimes, it crashes the first time, but works repeatably each session thereafter for the day. Sometimes, it's crash to desktop, sometimes it's a silent no-op, where a function just doesn't execute. The worst part -- every time I try a new solution, and it appears to be the right solution, but it'll eventually pop up again, but only for a select few customers.

 

Whack a mole with red herrings -- that's been my MO for some time now, which is why I'm eagerly following this thread.

Link to comment

Tom was able to track the problem down by painstakingly going through our source control and finding the point at which builds no longer worked.

 

It turns out that it CAN be traced back to when we pulled the 20 abstract classes out of their library. We have no idea why this caused such an obscure and massively catastrophic set of errors from LabVIEW. Can anyone provide any insight on that?

 

In the past, I've experienced some baffling and frustrating problems when pulling classes in or out of libraries. Nothing to this extent, but I'm wary of this operation (even moreso now!). Can anyone provide any insight as to why LabVIEW is so bad at handling what should be a simple organizational action?

 

Additionally, is there any way to fix this without having to revert all our source code back to that point and "start over" with all our feature additions? It's over 2 weeks' of coding that we'd basically have to reimplement.

Edited by Mike Le
  • Like 1
Link to comment

Just to (kind of) close the loop on this problem.  I'll summarize what we found.

 

A couple of weeks ago I removed about 20 (mostly abstract) classes from a library.  I did this by:

  1. Adding all of our source code to a new project (in order to load everything into memory).
  2. Right clicking on the classes in question and selecting "remove from library"

Our main VI continued to work afterwards, but the EXE started throwing a 1502 error.  Changing the "Additional Exclusions" settings as described in this thread didn't help any:

 

http://forums.ni.com/t5/LabVIEW/Error-while-creatiing-executable-Error-1502/td-p/669757

 

Anyone have any idea why removing classes from a library would cause the EXE, but not the VI to break?

  • Like 1
Link to comment
Additionally, is there any way to fix this without having to revert all our source code back to that point and "start over" with all our feature additions? It's over 2 weeks' of coding that we'd basically have to reimplement.

 

Here's what I would try -- this process anecdotally has helped me, and could help you as well:

  1. Ensure repo is up to date with all latest developments; ensure that you have no outstanding changesets or modifications to the working copy, and your team working in parallel has no outstanding modifications that could cause a conflict in SCC
  2. Open project
  3. From root node in project, right-click to "Properties >> Project page >> Mark Existing Items button >> ensure every item from dialogue is 'marked'"
  4. Save all
  5. Restart LabVIEW
  6. From GSW, Clear Compile Object Cache
  7. Restart LabVIEW
  8. These sub-steps are performed as one "transaction" within the context of one IDE session:

    1. Open project
    2. Recreate that parent library with the exact same name with your up-to-date repo
    3. Drag all your ~20 classes back into the library (i.e., the way it used to be)
    4. Mass compile (and perhaps, see lots of "problems")
    5. Mass compile once more (and probably, most/all "problems" go away)
    6. Drag all 20 classes back outside the library (i.e., the way you want it to be)
    7. Mass compile (and perhaps, see lots of "problems")
    8. Mass compile once more (and probably, most/all "problems" go away)
    9. Restart LabVIEW

[*]From GSW, clear compiled object cache

[*]Restart LabVIEW

[*]Open project -- build the EXE -- hopefully, the problem is gone. If so, commit to SCC, with a comment why you just modified 100's or 1000's of VIs

Link to comment

Here's what I would try -- this process anecdotally has helped me, and could help you as well:

  1. Ensure repo is up to date with all latest developments; ensure that you have no outstanding changesets or modifications to the working copy, and your team working in parallel has no outstanding modifications that could cause a conflict in SCC
  2. Open project
  3. From root node in project, right-click to "Properties >> Project page >> Mark Existing Items button >> ensure every item from dialogue is 'marked'"
  4. Save all
  5. Restart LabVIEW
  6. From GSW, Clear Compile Object Cache
  7. Restart LabVIEW
  8. These sub-steps are performed as one "transaction" within the context of one IDE session:

    1. Open project
    2. Recreate that parent library with the exact same name with your up-to-date repo
    3. Drag all your ~20 classes back into the library (i.e., the way it used to be)
    4. Mass compile (and perhaps, see lots of "problems")
    5. Mass compile once more (and probably, most/all "problems" go away)
    6. Drag all 20 classes back outside the library (i.e., the way you want it to be)
    7. Mass compile (and perhaps, see lots of "problems")
    8. Mass compile once more (and probably, most/all "problems" go away)
    9. Restart LabVIEW

[*]From GSW, clear compiled object cache

[*]Restart LabVIEW

[*]Open project -- build the EXE -- hopefully, the problem is gone. If so, commit to SCC, with a comment why you just modified 100's or 1000's of VIs

 

:blink: We need a W.T.F smiley!

  • Like 2
Link to comment

Here's what I would try -- this process anecdotally has helped me, and could help you as well:

  1. Ensure repo is up to date with all latest developments; ensure that you have no outstanding changesets or modifications to the working copy, and your team working in parallel has no outstanding modifications that could cause a conflict in SCC
  2. Open project
  3. From root node in project, right-click to "Properties >> Project page >> Mark Existing Items button >> ensure every item from dialogue is 'marked'"
  4. Save all
  5. Restart LabVIEW
  6. From GSW, Clear Compile Object Cache
  7. Restart LabVIEW
  8. These sub-steps are performed as one "transaction" within the context of one IDE session:

    1. Open project
    2. Recreate that parent library with the exact same name with your up-to-date repo
    3. Drag all your ~20 classes back into the library (i.e., the way it used to be)
    4. Mass compile (and perhaps, see lots of "problems")
    5. Mass compile once more (and probably, most/all "problems" go away)
    6. Drag all 20 classes back outside the library (i.e., the way you want it to be)
    7. Mass compile (and perhaps, see lots of "problems")
    8. Mass compile once more (and probably, most/all "problems" go away)
    9. Restart LabVIEW

[*]From GSW, clear compiled object cache

[*]Restart LabVIEW

[*]Open project -- build the EXE -- hopefully, the problem is gone. If so, commit to SCC, with a comment why you just modified 100's or 1000's of VIs

 

Thanks for the detailed response Jack.  I was able to get to step 8.3 before labview hung up on me for 2 hours.

Link to comment
"Fastest" being a relative term, but a couple weeks recoding is apparently faster than getting LabVIEW to resolve what should be a totally elementary organizational operation. This would be one of the "troughs" in our love/hate relationship with LabVIEW.

I feel your pain Mike,

 

This advice will probably come across as totally patronising (it really is not meant to be), but I really recommend nightly builds of all executables, committed into your VCS. Doing this generally saves a whole bunch of time when LabVIEW throws its toys out the cot.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.