Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ghidra stalls and the UI falters on Mac OS Big Sur #2531

Closed
bgdnext opened this issue Nov 28, 2020 · 28 comments
Closed

Ghidra stalls and the UI falters on Mac OS Big Sur #2531

bgdnext opened this issue Nov 28, 2020 · 28 comments

Comments

@bgdnext
Copy link

bgdnext commented Nov 28, 2020

I attempted to install and execute Ghidra on my Macbook Pro. Ghidra launches and loads an unresponsive UI with the Tip of the Day. The 'Next Tip' button changes from blue to grey in a flickering manner and is unresponsive. The whole dialog is unresponsive. I cycled through different versions of the JDK and Ghidra with the same result. I cannot move past the screen shot included.

Operating System: Mac OS Big Sur 11.0.1
JDK: attempted with AdoptOpenJDK 11 LTS (11.0.9.), AdoptOpenJDK 15 Latest (15.0.9), Oracle JDK SE 15.0.1
Ghidra Version: Attempted with 9.0, 9.1, 9.2

Screen Shot 2020-11-28 at 10 52 38 AM

@dev747368
Copy link
Collaborator

@bgdnext do you know if you can run other java gui apps on your system? Maybe try the java visualvm app to to see if its gui works.

@bgdnext
Copy link
Author

bgdnext commented Nov 28, 2020

ualvm

I just installed and ran VisualVM with no problems. I clicked through the GUI and it is working just fine.
Screen Shot 2020-11-28 at 5 23 04 PM

@ryanmkurtz
Copy link
Collaborator

ryanmkurtz commented Nov 30, 2020

I just installed the latest AdoptOpenJDK (11.0.9.1_1) on Big Sur and Ghidra 9.2 worked fine for me.

@dragonmacher
Copy link
Collaborator

@bgdnext When this happens, please run this diagnostic tool to provide the state of Ghidra when this happens.

From a terminal:
jps to get Ghidra's pid
jstack <pid> to get the stack info for all threads

@bgdnext
Copy link
Author

bgdnext commented Nov 30, 2020

So interesting progress. I tried to capture what was happening with GIPHY Capture and Ghidra opened up bypassing the Tip of the Day dialog. The functionality of the main window seems fine so it appears only the tip of the day dialog is the problem. When I open it from the HELP menu it still has the flickering button and is unresponsive.

@bgdnext
Copy link
Author

bgdnext commented Nov 30, 2020

@bgdnext When this happens, please run this diagnostic tool to provide the state of Ghidra when this happens.

From a terminal:
jps to get Ghidra's pid
jstack <pid> to get the stack info for all threads

brian@Brians-MacBook-Pro ghidra_9.2_PUBLIC % jstack 9738
2020-11-30 10:29:20
Full thread dump OpenJDK 64-Bit Server VM (11.0.9.1+1 mixed mode):

Threads class SMR info:
_java_thread_list=0x00007fc2a0b3da50, length=17, elements={
0x00007fc29e0c9000, 0x00007fc29f00f800, 0x00007fc29f055800, 0x00007fc29f04e000,
0x00007fc29f04f000, 0x00007fc29f05c800, 0x00007fc29d854800, 0x00007fc29f079800,
0x00007fc29e947000, 0x00007fc29e22d800, 0x00007fc2a1044000, 0x00007fc29d9e7000,
0x00007fc2a184d800, 0x00007fc29ebd1800, 0x00007fc29f372000, 0x00007fc29dc3d800,
0x00007fc2a20c2000
}

"Reference Handler" #2 daemon prio=10 os_prio=31 cpu=1.73ms elapsed=43.88s tid=0x00007fc29e0c9000 nid=0x4b03 waiting on condition [0x0000700006a10000]
java.lang.Thread.State: RUNNABLE
at java.lang.ref.Reference.waitForReferencePendingList([email protected]/Native Method)
at java.lang.ref.Reference.processPendingReferences([email protected]/Reference.java:241)
at java.lang.ref.Reference$ReferenceHandler.run([email protected]/Reference.java:213)

"Finalizer" #3 daemon prio=8 os_prio=31 cpu=1.48ms elapsed=43.88s tid=0x00007fc29f00f800 nid=0x4903 in Object.wait() [0x0000700006b13000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait([email protected]/Native Method)
- waiting on <0x0000000700620070> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove([email protected]/ReferenceQueue.java:155)
- waiting to re-lock in wait() <0x0000000700620070> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove([email protected]/ReferenceQueue.java:176)
at java.lang.ref.Finalizer$FinalizerThread.run([email protected]/Finalizer.java:170)

"Signal Dispatcher" #4 daemon prio=9 os_prio=31 cpu=0.33ms elapsed=43.86s tid=0x00007fc29f055800 nid=0xa803 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=31 cpu=6369.74ms elapsed=43.86s tid=0x00007fc29f04e000 nid=0xa703 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
No compile task

"C1 CompilerThread0" #8 daemon prio=9 os_prio=31 cpu=1936.23ms elapsed=43.86s tid=0x00007fc29f04f000 nid=0x5a03 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
No compile task

"Sweeper thread" #9 daemon prio=9 os_prio=31 cpu=66.78ms elapsed=43.86s tid=0x00007fc29f05c800 nid=0xa503 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"Common-Cleaner" #10 daemon prio=8 os_prio=31 cpu=2.05ms elapsed=43.83s tid=0x00007fc29d854800 nid=0x5d03 in Object.wait() [0x0000700007128000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait([email protected]/Native Method)
- waiting on <0x0000000700624030> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove([email protected]/ReferenceQueue.java:155)
- waiting to re-lock in wait() <0x0000000700624030> (a java.lang.ref.ReferenceQueue$Lock)
at jdk.internal.ref.CleanerImpl.run([email protected]/CleanerImpl.java:148)
at java.lang.Thread.run([email protected]/Thread.java:834)
at jdk.internal.misc.InnocuousThread.run([email protected]/InnocuousThread.java:134)

"Service Thread" #11 daemon prio=9 os_prio=31 cpu=0.04ms elapsed=43.81s tid=0x00007fc29f079800 nid=0xa003 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"DestroyJavaVM" #13 prio=5 os_prio=31 cpu=227.90ms elapsed=43.65s tid=0x00007fc29e947000 nid=0x1d03 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"Log4j2-TF-3-Scheduled-1" #16 daemon prio=5 os_prio=31 cpu=2.13ms elapsed=37.92s tid=0x00007fc29e22d800 nid=0x6503 waiting on condition [0x0000700007a43000]
java.lang.Thread.State: TIMED_WAITING (parking)
at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
- parking to wait for <0x0000000700dd9d78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos([email protected]/LockSupport.java:234)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos([email protected]/AbstractQueuedSynchronizer.java:2123)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take([email protected]/ScheduledThreadPoolExecutor.java:1182)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take([email protected]/ScheduledThreadPoolExecutor.java:899)
at java.util.concurrent.ThreadPoolExecutor.getTask([email protected]/ThreadPoolExecutor.java:1054)
at java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.java:1114)
at java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.java:628)
at java.lang.Thread.run([email protected]/Thread.java:834)

"AppKit Thread" #17 daemon prio=5 os_prio=31 cpu=16494.94ms elapsed=37.86s tid=0x00007fc2a1044000 nid=0x307 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"AWT-Shutdown" #18 prio=5 os_prio=31 cpu=0.72ms elapsed=37.80s tid=0x00007fc29d9e7000 nid=0xab03 in Object.wait() [0x0000700007b46000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait([email protected]/Native Method)
- waiting on
at java.lang.Object.wait([email protected]/Object.java:328)
at sun.awt.AWTAutoShutdown.run([email protected]/AWTAutoShutdown.java:291)
- waiting to re-lock in wait() <0x0000000700ddc998> (a java.lang.Object)
at java.lang.Thread.run([email protected]/Thread.java:834)

"AWT-EventQueue-0" #19 prio=6 os_prio=31 cpu=1792.77ms elapsed=37.70s tid=0x00007fc2a184d800 nid=0xc403 waiting on condition [0x0000700007f5b000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
- parking to wait for <0x0000000700ddcca8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park([email protected]/LockSupport.java:194)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await([email protected]/AbstractQueuedSynchronizer.java:2081)
at java.awt.EventQueue.getNextEvent([email protected]/EventQueue.java:566)
at java.awt.EventDispatchThread.pumpOneEventForFilters([email protected]/EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEventsForFilter([email protected]/EventDispatchThread.java:124)
at java.awt.EventDispatchThread.pumpEventsForHierarchy([email protected]/EventDispatchThread.java:113)
at java.awt.EventDispatchThread.pumpEvents([email protected]/EventDispatchThread.java:109)
at java.awt.EventDispatchThread.pumpEvents([email protected]/EventDispatchThread.java:101)
at java.awt.EventDispatchThread.run([email protected]/EventDispatchThread.java:90)

"Java2D Queue Flusher" #20 daemon prio=10 os_prio=31 cpu=873.94ms elapsed=37.63s tid=0x00007fc29ebd1800 nid=0xd103 in Object.wait() [0x0000700008367000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait([email protected]/Native Method)
- waiting on
at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run([email protected]/OGLRenderQueue.java:205)
- waiting to re-lock in wait() <0x0000000700ddfac0> (a sun.java2d.opengl.OGLRenderQueue$QueueFlusher)
at java.lang.Thread.run([email protected]/Thread.java:834)

"Java2D Disposer" #21 daemon prio=10 os_prio=31 cpu=0.54ms elapsed=37.55s tid=0x00007fc29f372000 nid=0xe203 in Object.wait() [0x000070000846a000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait([email protected]/Native Method)
- waiting on <0x0000000700de2640> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove([email protected]/ReferenceQueue.java:155)
- waiting to re-lock in wait() <0x0000000700de2640> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove([email protected]/ReferenceQueue.java:176)
at sun.java2d.Disposer.run([email protected]/Disposer.java:144)
at java.lang.Thread.run([email protected]/Thread.java:834)

"TimerQueue" #23 daemon prio=5 os_prio=31 cpu=63.07ms elapsed=36.34s tid=0x00007fc29dc3d800 nid=0xf13b waiting on condition [0x0000700008670000]
java.lang.Thread.State: TIMED_WAITING (parking)
at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
- parking to wait for <0x0000000700dda1e0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos([email protected]/LockSupport.java:234)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos([email protected]/AbstractQueuedSynchronizer.java:2123)
at java.util.concurrent.DelayQueue.take([email protected]/DelayQueue.java:229)
at javax.swing.TimerQueue.run([email protected]/TimerQueue.java:171)
at java.lang.Thread.run([email protected]/Thread.java:834)

"Attach Listener" #27 daemon prio=9 os_prio=31 cpu=1.10ms elapsed=0.10s tid=0x00007fc2a20c2000 nid=0x15d03 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"VM Thread" os_prio=31 cpu=44.56ms elapsed=43.88s tid=0x00007fc29e861800 nid=0x3a03 runnable

"GC Thread#0" os_prio=31 cpu=29.45ms elapsed=43.90s tid=0x00007fc29e012800 nid=0x3003 runnable

"GC Thread#1" os_prio=31 cpu=29.66ms elapsed=38.35s tid=0x00007fc29dad7000 nid=0x3e0f runnable

"GC Thread#2" os_prio=31 cpu=31.94ms elapsed=38.35s tid=0x00007fc29e008800 nid=0x6303 runnable

"GC Thread#3" os_prio=31 cpu=26.63ms elapsed=38.35s tid=0x00007fc29dad8000 nid=0x9c03 runnable

"GC Thread#4" os_prio=31 cpu=32.33ms elapsed=38.35s tid=0x00007fc29dadf000 nid=0x9a03 runnable

"GC Thread#5" os_prio=31 cpu=29.05ms elapsed=38.35s tid=0x00007fc29eb16800 nid=0x9803 runnable

"GC Thread#6" os_prio=31 cpu=24.81ms elapsed=37.68s tid=0x00007fc29db75800 nid=0xcc0b runnable

"GC Thread#7" os_prio=31 cpu=23.59ms elapsed=37.68s tid=0x00007fc29f35e800 nid=0x12603 runnable

"G1 Main Marker" os_prio=31 cpu=0.77ms elapsed=43.90s tid=0x00007fc29f046800 nid=0x5203 runnable

"G1 Conc#0" os_prio=31 cpu=17.00ms elapsed=43.90s tid=0x00007fc29e013000 nid=0x3303 runnable

"G1 Conc#1" os_prio=31 cpu=16.33ms elapsed=37.67s tid=0x00007fc2a2029800 nid=0x12503 runnable

"G1 Refine#0" os_prio=31 cpu=1.00ms elapsed=43.89s tid=0x00007fc29e0c1000 nid=0x3503 runnable

"G1 Young RemSet Sampling" os_prio=31 cpu=8.17ms elapsed=43.89s tid=0x00007fc29f047800 nid=0x3603 runnable
"VM Periodic Task Thread" os_prio=31 cpu=17.82ms elapsed=43.81s tid=0x00007fc29d85f000 nid=0x5f03 waiting on condition

JNI global refs: 190, weak refs: 1308

@dragonmacher
Copy link
Collaborator

Thanks for the info. All seems to be functioning normally there. The dialog you mentioned is non-modal. If you move it to the side, can you interact with Ghidra? Can you close the dialog?

@bgdnext
Copy link
Author

bgdnext commented Nov 30, 2020

TipOfDayIssue

I cannot move it to the side. When it is active the rest of the application is not reachable.

@dragonmacher
Copy link
Collaborator

You can try disabling the Tips dialog via Ghidra preferences.

Close Ghidra. Edit:
<user home>/.ghidra/.ghidra_<version>/preferences

Add this line to that file:
SHOW_TIPS=false

Run Ghidra and the dialog should not appear.

@bgdnext
Copy link
Author

bgdnext commented Nov 30, 2020

You can try disabling the Tips dialog via Ghidra preferences.

Close Ghidra. Edit:
<user home>/.ghidra/.ghidra_<version>/preferences

Add this line to that file:
SHOW_TIPS=false

Run Ghidra and the dialog should not appear.

Does this file exist or does it have to be created? I don't have this path to preferences after decompressing the Ghidra download package.

@dragonmacher
Copy link
Collaborator

Once you have run Ghidra, the above path should be there. It is a 'dot' directory, so it may not be visible from your Finder, but you can see it from the terminal with a ls -latr.

@bgdnext
Copy link
Author

bgdnext commented Nov 30, 2020

Alright thank you. I mistakenly started at the ghidra root and not my home as root. I have it set to false and now I am able to use Ghidra. Hopefully there is a fix for the tips but I will just google what I need to know haha. Thanks.

@ghizard
Copy link
Contributor

ghizard commented Dec 2, 2020

@ryanmkurtz
Did your window manager put the Tip of the Day and the Project Window both as tabs on the same window?
Just curious. I asked, but @dragonmacher does not think it would cause a deadlock.

@bgdnext
Copy link
Author

bgdnext commented Dec 2, 2020

@ryanmkurtz
Did your window manager put the Tip of the Day and the Project Window both as tabs on the same window?
Just curious. I asked, but @dragonmacher does not think it would cause a deadlock.

This is what happened to me yes.

@KwisatzJim
Copy link

I had the same problem and the change to the preferences file fixed that. But now every time I import a file the app locks up just like it did with the tip of the day issue

@ryanmkurtz
Copy link
Collaborator

@ghizard, no, it looked and behaved 100% normal for me.

@dragonmacher
Copy link
Collaborator

It seems to me that the common factor is how the OS/window manager is putting each dialog in a tab. I do not recognize the tab structure shown in the screenshots. Is this a native mac windowing environment, or some add-on window manager?

@ryanmkurtz
Copy link
Collaborator

This is on x86 mac and not M1 right?

@KwisatzJim
Copy link

yes

@ryanmkurtz
Copy link
Collaborator

For my state that works fine, I'm using AdoptOpenJDK 11.0.9.1 on a MacBook Pro (16-inch, 2019) with Big Sur 11.0.1. I also made sure to stick this version of the JDK at the front of my PATH to guarantee Ghidra uses it instead of some other version I have on my machine.

@bgdnext
Copy link
Author

bgdnext commented Dec 3, 2020

For the record my computer is a Macbook Pro Late 2013 Retina 15-inch. That's the only difference between mine and yours @ryanmkurtz

@ZakVanstrom
Copy link

bumping identical issues:

using MacOS 11.0.1 on MacBook Pro 16" (late 2019), but with plain OpenJDK

  1. Froze on tips menu
    1.a used >80% of cpu in activity monitor
    1.b did not respond to normal closing, needed force quit
  2. Solved above via preferences fix
  3. Froze on import menu
    3.a same as 1.a, 1.b
  4. Closed app, reopened, file was imported correctly
  5. attempted analysis when prompted
  6. froze again, but eventually loaded to analysis options, but still unresponsive
  7. skipped analysis, then the code editor loaded correctly and was responsive <-- am here

@dyunus
Copy link

dyunus commented Dec 6, 2020

I believe issues are arising with the way the window tabbing happens in Big Sur.

System Preferences -> General -> Prefer tabs: -> Set to "never"

This fixed Ghidra for me on Big Sur, 13" MBP x86

@bgdnext
Copy link
Author

bgdnext commented Dec 6, 2020

Changing the tab setting in Big Sur to never fixed the tip of the day window for me!!!

@born4new
Copy link

I don't think changing a OS-wide setting for an app to behave is a nice fix...I would keep that ticket or #2711 open.

@dragonmacher
Copy link
Collaborator

I don't think changing a OS-wide setting for an app to behave is a nice fix

I agree. This is currently just a workaround and not a fix. My guess is that the real issue is how the JVM is interacting with that Mac setting. It is quite possible that future JVMs will have addressed this issue.

In the interim, this would be a great opportunity for the community to provide a better solution. What can be done in Ghidra's VM setup and usage to fix this issue?

@dyunus
Copy link

dyunus commented Apr 18, 2021

I don't think changing a OS-wide setting for an app to behave is a nice fix...I would keep that ticket or #2711 open.

Agreed. Never meant for my comment to be considered the "fix", but given that I needed to use Ghidra pretty urgently and that was the only way I was able to, I figured others could benefit as well in the time being

@icedice
Copy link

icedice commented Apr 26, 2021

I wonder why setting defaults write net.java.openjdk.cmd AppleWindowTabbingMode manual does not fix the issue.

This fixes the issue for other Java apps without interfering with the native MacOS apps and non Java apps. Not a good solution but better than messing with the global setting. But unfortunately it does not seem to work for Ghidra.


Edit: As it turns out it DOES work. You just need to be more specific and use the JRE version. This worked for me defaults write net.java.openjdk.11.0.10.java "AppleWindowTabbingMode" manual

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants