Ghidra takes a very long time to save on Linux compared to Windows #7258
Assignees
Labels
Status: Triage
Information is being gathered
Comments
|
We would need more information to diagnose this issue. What is a very long time? seconds, minutes, hours, never finish the save? It is very possible it is the way you are running it on Linux, your system setup, linux under WSL on windows, your file system setup, etc... We haven't had any other reports of this issue, so it is possible it is a local configuration problem. Is this something new that just started to occur? Are you running a release copy, or are you running under development/debug in eclipse? You can cause Ghidra to dump the thread stack to see where it is spending time. |
|
Please provide a thread listing using java's jstack tool when in the bad state. From a terminal, execute: |
|
I can confirm that this does occur on windows too. It is not easily reproducible but I usually see it occur when I have huge programs open (several gb). It does not occur on every save. |
|
|
Actually not deadlocked. It is writing. If you were to bring up the same program with just a simple change, would it happen again? Does it stay this way forever, or eventually save? How long v.s. windows if it does save. |
I'm not sure if it's the same as the op, but for me it's usually trivial like changing a single label or data (I'm a paranoid saver) |
|
only made one tiny change and it still took a long time to save |
|
Since this is a sporadic issue, it can be hard to diagnose. 1.2GB does seem rather large for an 8MB orignal binary, unless there are multiple programs in the .rep. Possible there is some sort of bad feedback interaction between the backup save and the actual save on exit. It seems like two threads saving the program are involved. One is checking if the program has changed, and the other is writing it. I've used visualvm to diagnose these types of issues, but it can be hard to pick out the real issue, and your issues seems sproadic. You could also dump the stack wiith jstack repetitively to see if anything becomes apparent with the two threads. |
|
i dumped the stack in #7258 (comment) |
|
I meant repeatedly dump the stack 2-3 times every 20 seconds or so while it is in this state. visualvm is a better way to do it because it is recording, but there is a learning curve and easy to misinterpret the results. Plus you can't attach them to the ticket. |
|
The issue appears to be purely based on a database save operation which is taking too long. The save is done by a modal task which will prevent the user from interacting with most of the GUI (other than task cancel button if present). Unfortunately, the save operation triggered an undo stack collapse which notified the MultiProgramListener which is attempting to update its undo/redo action state. This is blocked and in turn is blocking the swing thread which prevents subsequent task monitor updates or the ability to cancel save task. This should all free-up once the save actually completes. I will see if the undoStackChanged notification can be deferred until after the save operation has completed to avoid this GUI blocking in this case. |
|
It is also interesting that the file has been completely written and is in the final steps of transitioning the buffer file to read-only. If at any point in the database's life a large amount of data was removed (e.g., initialized memory blocks) this could cause a large number of free buffers to exist. Every time the file is saved the free buffer chain is updated. That may account for why it was caught in the state where it is updating the free-buffer chain within the buffer file. |
I verified that it is unlikely that the |
|
I will look into removing synchronized from |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
it would get stuck at this screen
using Ubuntu 24.04.1 LTS
and this fork/branch: https://github.com/H-A-M-G-E-R/ghidra/tree/switch-case-order (the only change i made is unrelated to this problem)
but also affects the 11.2.1 release
Windows 11 doesn't have this problem
The text was updated successfully, but these errors were encountered: