ghidra icon indicating copy to clipboard operation
ghidra copied to clipboard

Ghidra 11.0 can't open program created in Ghidra 10.4

Open artemy opened this issue 6 months ago • 5 comments

Describe the bug Ghidra 11.0 can't open program created in Ghidra 10.4 with "File was created with an unknown version of Ghidra" error

To Reproduce Steps to reproduce the behavior:

  1. Install Ghidra 11.0
  2. Open project created with Ghidra 10.4
  3. Open any of the programs in the project
  4. See error

Environment (please complete the following information): Build Date: 2023-Dec-22 0936 EST Ghidra Version: 11.0 JVM Version: Eclipse Adoptium 21.0.1 OS: Mac OS X 14.2.1 aarch64

Another important detail: Project was using ghidra-xtensa decompiler https://github.com/Ebiroll/ghidra-xtensa, which is now included in Ghidra 11.0 by default (or a version of)

artemy avatar Dec 25 '23 11:12 artemy

@artemy Hi, and sorry to hear you're having issues. I think this may be related to your last comment, as I'm not able to reproduce your results. Specifically, I created two 10.4 projects, one with and one without the Ebirolli/ghidra-xtensa package added, imported a few files, and then re-opened them with 11.0 without any obvious problems. My env is very close, albeit not identical, to yours: Ghidra 11.0, OpenJDK JVM Temurin 21.0, Mac OS X 14.2.1 aarch64 (M1).

That said, I did NOT import any actual Xtensa files, so leaning toward that being the root of the problem. Will try to get an Xtensa example and re-test. At a guess (and definitely a guess), the original Ebirolli project didn't specify the language version or had a language version not recognized by 11.0. Will ask the team whether there's a workaround for this tomorrow.

d-millar avatar Dec 25 '23 21:12 d-millar

save a backup of course of your project.

I would open your /Ghira/Processors/Xtensa/data/languages/xtensa.ldefs

Copy the id="Xtensa:LE:32:default XML element and change this line to something else id="Xtensa:LE:32:default_tmp and change the variant line to the same

reopen ghidra, right click your project, set language to default_tmp, save, repeat but with default. remove changes to your ldefs file.

mumbel avatar Dec 25 '23 23:12 mumbel

save a backup of course of your project.

I would open your /Ghira/Processors/Xtensa/data/languages/xtensa.ldefs

Copy the id="Xtensa:LE:32:default XML element and change this line to something else id="Xtensa:LE:32:default_tmp and change the variant line to the same

reopen ghidra, right click your project, set language to default_tmp, save, repeat but with default. remove changes to your ldefs file.

I tried your advice, but unfortunately this didn't help.

Trying to open "Set Language" fails with the following error:

2023-12-26	19:48:24	ERROR	(SetLanguageTask) File Error: java.io.IOException: Open failed: Set language aborted - program user data is now in an unusable state! java.io.IOException: Open failed: Set language aborted - program user data is now in an unusable state!
			at ghidra.program.database.ProgramContentHandler.getDomainObject(ProgramContentHandler.java:211)
			at ghidra.program.database.ProgramContentHandler.getDomainObject(ProgramContentHandler.java:42)
			at ghidra.framework.data.GhidraFileData.getDomainObject(GhidraFileData.java:509)
			at ghidra.framework.data.GhidraFile.getDomainObject(GhidraFile.java:231)
			at ghidra.app.plugin.core.processors.LanguageProviderPlugin$SetLanguageTask.run(LanguageProviderPlugin.java:213)
			at ghidra.util.task.Task.monitoredRun(Task.java:134)
			at ghidra.util.task.TaskRunner.lambda$startTaskThread$0(TaskRunner.java:106)
			at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
			at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
			at java.base/java.lang.Thread.run(Thread.java:1583)
			Caused by: java.lang.IllegalStateException: Set language aborted - program user data is now in an unusable state!
			at ghidra.program.database.ProgramUserDataDB.setLanguage(ProgramUserDataDB.java:442)
			at ghidra.program.database.ProgramUserDataDB.<init>(ProgramUserDataDB.java:203)
			at ghidra.program.database.ProgramContentHandler.getProgramUserData(ProgramContentHandler.java:237)
			at ghidra.program.database.ProgramContentHandler.getDomainObject(ProgramContentHandler.java:195)
			... 9 more
			Caused by: java.lang.NullPointerException: Cannot invoke "ghidra.program.util.LanguageTranslator.getNewLanguage()" because "translator" is null
			at ghidra.program.database.ProgramUserDataDB.setLanguage(ProgramUserDataDB.java:421)
			... 12 more

artemy avatar Dec 26 '23 18:12 artemy

My instructions were a little unclear after re-reading them myself... I am assuming you have a program Xtensa:LE:32:default (do the default_tmp for BE if otherwise)

You'll have three <language processor="Xtensa" entries total (2 current "default" for LE and BE, 1 temporary "default_tmp" for LE). The temporary copied element differs from the other LE in the variant="default" and id="Xtensa:LE:32:default" lines

This let me go from the stale "Xtensa:LE:32:default" -> temporary "Xtensa:LE:32:default_tmp" -> new "Xtensa:LE:32:default"

I had 2 programs I did this with successfully with Ebiroll or Yath's repo, I cant remember, they were rather old files from when the MR originally opened.

mumbel avatar Dec 26 '23 19:12 mumbel

Your original implementation is at version 1.0 while ours is 4.0. This was done for internal reasons. If you like, you can create an old language mapping/translator if this will be a recurring situation.

This starts with generating an "old" language XML file using the GenerateOldLanguagePlugin which can be added to the Project window using your old Ghidra version that contained the 1.0 language. Run the file->Generate Old Language File... action and select your Xtensa language. We usually create a Xtensa/data/languages/old directory to contain the resulting *.old file. Copy this into your new install of Ghidra 11.0.

Using the new version of Ghidra add this plugin run File->Generate Simple Lanaguage Translator... selecting the old language you produced above as the from-language and the new 4.0 language as the to-language. This will produce a *.trans file which should be stored alongside the *.old language.

Although I have never tried skipping versions, I am hoping it will handle the 1.0 to 4.0 leap.

Some of this should be discussed in the docs/languages/versioning.html document.

ghidra1 avatar Dec 28 '23 17:12 ghidra1

I have the same exact problem; if it is useful, I can provide the project directory. Using @mumbel 's second instructions did not help and resulted in the same error that @artemy had; I will rollback to what I had before.

redfast00 avatar Jan 17 '24 18:01 redfast00

By following @ghidra1's instructions (excellent instructions btw); I managed to get my project updated. The translator generator did show a warning (but seems to work from a quick glance):

image

To help other people out, I've shared the files: they upgrade from Ebiroll's repo (https://github.com/Ebiroll/ghidra-xtensa commit 4e1aa22f76b6350d018094dfedeefe4b9096d9e1) to Ghidra 11.0 Xtensa language 4.0.

xtensa_ebiroll_4e1aa22_to_mainline_4.zip

redfast00 avatar Jan 18 '24 18:01 redfast00

@artemy has sufficient information been provided that we may close this ticket?

ghidra1 avatar Jan 18 '24 23:01 ghidra1

@artemy has sufficient information been provided that we may close this ticket?

I ended up recreating the project, so the issue is resolved

artemy avatar Jan 19 '24 09:01 artemy