`UnresolvedClassTypeInfoException`: Unable to locate archived data

Unable to locate archived data for MWF::ObjActiveBase::typeinfo
ghidra.app.cmd.data.rtti.gcc.UnresolvedClassTypeInfoException: Unable to locate archived data for MWF::ObjActiveBase::typeinfo
	at cppclassanalyzer.plugin.ClassTypeInfoManagerPlugin.getExternalClassTypeInfo(ClassTypeInfoManagerPlugin.java:331)
	at cppclassanalyzer.data.manager.ItaniumAbiClassTypeInfoManager.getExternalClassTypeInfo(ItaniumAbiClassTypeInfoManager.java:77)
	at ghidra.app.cmd.data.rtti.gcc.typeinfo.AbstractSiClassTypeInfoModel.getParentModels(AbstractSiClassTypeInfoModel.java:42)
	at ghidra.app.cmd.data.rtti.gcc.typeinfo.SiClassTypeInfoModel.getParentModels(SiClassTypeInfoModel.java:15)
	at ghidra.app.cmd.data.rtti.gcc.typeinfo.AbstractSiClassTypeInfoModel.getVirtualParents(AbstractSiClassTypeInfoModel.java:47)
	at ghidra.app.cmd.data.rtti.gcc.typeinfo.SiClassTypeInfoModel.getVirtualParents(SiClassTypeInfoModel.java:15)
	at cppclassanalyzer.data.typeinfo.GnuClassTypeInfoDB.fillModelData(GnuClassTypeInfoDB.java:272)
	at cppclassanalyzer.data.typeinfo.AbstractClassTypeInfoDB.<init>(AbstractClassTypeInfoDB.java:67)
	at cppclassanalyzer.data.typeinfo.GnuClassTypeInfoDB.<init>(GnuClassTypeInfoDB.java:49)
	at cppclassanalyzer.data.manager.ItaniumAbiClassTypeInfoManager$GnuRttiRecordWorker.buildType(ItaniumAbiClassTypeInfoManager.java:308)
	at cppclassanalyzer.data.manager.ItaniumAbiClassTypeInfoManager$GnuRttiRecordWorker.buildType(ItaniumAbiClassTypeInfoManager.java:295)
	at cppclassanalyzer.data.manager.AbstractRttiRecordWorker.resolve(AbstractRttiRecordWorker.java:143)
	at cppclassanalyzer.data.manager.ClassTypeInfoManagerDB.resolve(ClassTypeInfoManagerDB.java:401)
	at cppclassanalyzer.data.manager.ItaniumAbiClassTypeInfoManager.getTypeInfo(ItaniumAbiClassTypeInfoManager.java:59)
	at cppclassanalyzer.data.manager.ClassTypeInfoManagerDB.getType(ClassTypeInfoManagerDB.java:336)
	at cppclassanalyzer.data.manager.ClassTypeInfoManagerDB.getType(ClassTypeInfoManagerDB.java:353)
	at cppclassanalyzer.data.manager.ClassTypeInfoManagerDB.getType(ClassTypeInfoManagerDB.java:369)
	at cppclassanalyzer.decompiler.action.FillOutClassAction.isEnabledForDecompilerContext(FillOutClassAction.java:36)
	at ghidra.app.plugin.core.decompile.actions.AbstractDecompilerAction.lambda$isEnabledForContext$0(AbstractDecompilerAction.java:68)
	at ghidra.app.plugin.core.decompile.DecompilerActionContext.checkActionEnablement(DecompilerActionContext.java:147)
	at ghidra.app.plugin.core.decompile.actions.AbstractDecompilerAction.isEnabledForContext(AbstractDecompilerAction.java:67)
	at docking.ComponentPlaceholder.contextChanged(ComponentPlaceholder.java:532)
	at docking.DockingWindowManager.contextChanged(DockingWindowManager.java:2232)
	at docking.AbstractDockingTool.contextChanged(AbstractDockingTool.java:208)
	at ghidra.framework.plugintool.PluginTool.contextChanged(PluginTool.java:1433)
	at ghidra.app.plugin.core.decompile.DecompilerProvider.contextChanged(DecompilerProvider.java:675)
	at ghidra.app.plugin.core.decompile.DecompilerProvider.decompileDataChanged(DecompilerProvider.java:505)
	at ghidra.app.decompiler.component.DecompilerController.setDecompileData(DecompilerController.java:181)
	at ghidra.app.decompiler.component.DecompilerController.loadFromCache(DecompilerController.java:128)
	at ghidra.app.decompiler.component.DecompilerController.display(DecompilerController.java:105)
	at ghidra.app.plugin.core.decompile.DecompilerProvider.setLocation(DecompilerProvider.java:422)
	at ghidra.app.plugin.core.decompile.DecompilePlugin.lambda$new$0(DecompilePlugin.java:75)
	at ghidra.util.task.SwingUpdateManager.swingDoWork(SwingUpdateManager.java:108)
	at ghidra.util.task.AbstractSwingUpdateManager.swingExecutePendingWork(AbstractSwingUpdateManager.java:338)
	at ghidra.util.task.AbstractSwingUpdateManager.timerCallback(AbstractSwingUpdateManager.java:287)
	at ghidra.util.task.AbstractSwingUpdateManager.lambda$new$0(AbstractSwingUpdateManager.java:131)
	at java.desktop/javax.swing.Timer.fireActionPerformed(Timer.java:317)
	at java.desktop/javax.swing.Timer$DoPostEvent.run(Timer.java:249)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

I’m getting this exception when clicking anywhere in a particular function, which comes up as a modal dialog. This unfortunately makes it impossible to work on the function.

Any ideas for how I can work around this?

I’m also wondering if I’m doing something wrong with my workflow that may have led to this. I have multiple .so files that are all part of the same Ghidra project. These libraries inherit classes from each other in some cases, so presumably there’s RTTI dependencies between them. I saw a note about this in the readme, but I don’t quite understand how to handle this. Am I to open all .so files in the project and analyze them with the RTTI analyzers in dependency order?

Also, what happens if you rerun the RTTI analyzers? Will they overwrite data types you’ve already worked on? Under what circumstances should they be rerun?

Let me know if there’s any more info I can provide to help. Thanks!

[astrelsky]

Most of the problems due to ebo will go away with 10.2 as the decompiler finally has union support

That should be nice! Fingers crossed that there will be an easy way to rerun analysis to unionize the vtable types. I see there is currently some union support in Ghidra. What exactly is coming in 10.2?

Create a project archive in the ClassTypeInfo tree (the tree that appears when clicking the c++ toolbar icon).

I noticed that when I open multiple programs in one Ghidra session, all of the programs already show up in the ClassTypeInfo tree. I tried doing this and then rerunning analysis, but it didn’t seem to pick up the dynamic classes. I believe some of my types were overwritten as well, so I ended up restoring to a backup I made just beforehand.

This issue can probably be closed FWIW, since the fix for the original issue is merged. Perhaps you might consider enabling GitHub Discussions for this project, but I imagine you’ve already considered this.

I’m aware of the multiple archives showing, I just haven’t figured out or bothered figuring out how to hide the archive node. Each manager for a program is directly tied to it just like a DataTypeManager and analysis on another program shouldn’t have any effect on it.

As for discussions… 🤦‍♂️ I saw the tab available and didn’t realize I had to enable them. Mentioning it prompted me to click into the tab and I do indeed need to enable it. It should be enabled now even though I canceled the stupid announcement one it wanted me to make.

I tend to avoid closing issues myself because I’ve been informed that when I close it manually or by auto linking the issue author can’t re-open it.

[kevinhartman]

Most of the problems due to ebo will go away with 10.2 as the decompiler finally has union support

That should be nice! Fingers crossed that there will be an easy way to rerun analysis to unionize the vtable types. I see there is currently some union support in Ghidra. What exactly is coming in 10.2?

Create a project archive in the ClassTypeInfo tree (the tree that appears when clicking the c++ toolbar icon).

I noticed that when I open multiple programs in one Ghidra session, all of the programs already show up in the ClassTypeInfo tree. I tried doing this and then rerunning analysis, but it didn’t seem to pick up the dynamic classes. I believe some of my types were overwritten as well, so I ended up restoring to a backup I made just beforehand.

This issue can probably be closed FWIW, since the fix for the original issue is merged. Perhaps you might consider enabling GitHub Discussions for this project, but I imagine you’ve already considered this.