cyberkaida
ReVa stops responding after a while
Sometimes ReVa just stops working, and the tool calls just hang forever. A screenshot as example:
I have to restart Claude in order for it to start working again. Maybe the connection somehow gets lost?
Can you try a build off the main branch? I think I fixed this in #96 I have one more small change I need to make before the next release.
If you are getting this issue with the main branch please let me know what commit you are using and I will try to reproduce.
I let Claude-Code analyze a project overnight. It seemed to work, though it only worked on it for about an hour, so it wasn't a long test after all.
Now, another few hours later, I ask it to continue using ReVa... but it's not receiving a response again, getting stuck in a set-comment action.
So I restarted Claude-Code only (not Ghidra), and now it's working again.
Another small update: it just stopped working again, after a session of only 30 minutes. Tried to use a ReVa tool, and it didn't do anything. A simple restart of Claude-Code made it work again.
Aha, now I've encountered a ReVa get-decompilation tool call that always hangs. (I don't see Ghidra doing anything in my htop output)
The call looks rather simple:
ReVa:get-decompilation (MCP)(programPath: "trafficgiant.exe", functionNameOrAddress: "0x0050563c",includeComments: true, limit: 50)
This time I restarted both Claude-Code and Ghidra, bot nothing is working.
*Edit: It kept blocking on getting the decompiled version of that function, so I just manually supplied it instead. Then it tried to get the decompiled representation of some other functions, and those just worked immediately.
#137
There is a new transport with a "resume" option in the new version of MCP. This transport will be much more reliable.
I have added limits to the references in decompilation to fix issues there and I have added a timeout to the decompilation request. This should fix your issue with the big function with many references.
Just a small extra update that might be useful: it still happens. And sometimes it's not because of references, sometimes a get-decompilation will also not return anything. (Then I restart, as it to try again, and it returns in under a second)
Just a small extra update that might be useful: it still happens. And sometimes it's not because of references, sometimes a
get-decompilationwill also not return anything. (Then I restart, as it to try again, and it returns in under a second)
Yeah, that happens because it's also requesting the decompilation be annotated with cross references, which makes it time out. try telling it that if it gets a response that the request timed out that it should try without cross references.
@skerit @ILOVEPIE I have made a change to add timeouts to the MCP server. I also made a change to add a lot of debug logging (needs to be enabled in the settings menu). If you would like to try in #144
You can find the logs by going to this computer icon on the project view:
In the log view you can click the directory icon on the top:
The log will be the application.log
If you can reproduce with the debug log enabled and send me this I can try to debug the issue.
Thank you for your help! 🙇♀
@cyberkaida Sorry to say it's still happening. Even with the latest version. In a totally different project, even.
I'll enable the debug log and try to get back to you.
I have seen this with the new transport too. I did a /mcp reconnect ReVa and it started working again. I need to debug this.
The debug logs are stored with the other Ghidra logs (~/Library/ghidra/ghidra_11.4_PUBLIC/application.log for example on macOS)
I can see that back in the 11.3 versions, there was indeed debug information in the ~/.config/ghidra/ghidra_11.3.2_PUBLIC/application.log file
But now when I look at the ~/.config/ghidra/ghidra_11.4.2_DEV/application.log file, there's nothing in there about ReVa specifically. Even though debugging is on.
I did see this exception, but I'm not sure if that's a ReVa or just a Ghidra issue:
2025-10-20 12:23:01 ERROR (InternalResultListener) Unexpected exception getting Decompiler result java.util.concurrent.ExecutionException: java.util.ConcurrentModificationException
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at generic.concurrent.QResult.<init>(QResult.java:40)
at generic.concurrent.FutureTaskMonitor.run(FutureTaskMonitor.java:78)
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:1570)
Caused by: java.util.ConcurrentModificationException
at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1229)
at ghidra.app.extension.datatype.finder.DtrfDbg.println(DtrfDbg.java:94)
at ghidra.app.extension.datatype.finder.DecompilerDataTypeReferenceFinder$DecompilerDataTypeFinder.searchDecompilation(DecompilerDataTypeReferenceFinder.java:330)
at ghidra.app.extension.datatype.finder.DecompilerDataTypeReferenceFinder$DecompilerDataTypeFinder.findUsage(DecompilerDataTypeReferenceFinder.java:312)
at ghidra.app.extension.datatype.finder.DecompilerDataTypeReferenceFinder$DecompilerDataTypeFinderQCallback.process(DecompilerDataTypeReferenceFinder.java:267)
at ghidra.app.extension.datatype.finder.DecompilerDataTypeReferenceFinder$DecompilerDataTypeFinderQCallback.process(DecompilerDataTypeReferenceFinder.java:238)
at ghidra.app.decompiler.parallel.DecompilerCallback.process(DecompilerCallback.java:80)
at ghidra.app.decompiler.parallel.DecompilerCallback.process(DecompilerCallback.java:41)
at generic.concurrent.ConcurrentQ$CallbackCallable.call(ConcurrentQ.java:666)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at generic.concurrent.FutureTaskMonitor.run(FutureTaskMonitor.java:76)
... 3 more
Even in the 11.4 version ReVa stops working a lot.