Emulator

Possibly related to #10815

For future reference, #11424 generates a panic alert to test this issue.

I've been testing this pretty much all day, and I've crashed Dolphin a few times with GPU desyncs. Since it doesn't rotate, I haven't had it just instantly quit on me.

I just has this issue occur in 5.0-9224 so it should remain open.

Instantiation was originally disallowed in NativeLibrary. I assume this is because it wasn't necessary rather than doing so causes problems. Is it alright if I allow instantiation to let DialogFragment handle AlertDialogs during rotation?

Assuming you mean that instantiation of NativeLibrary is disallowed (I wasn't sure what you meant at first), then... I don't really see how allowing that would make sense. Could you explain further about in what way being able to create instances of NativeLibrary would help?

JosJuice wrote:

Instantiation was originally disallowed in NativeLibrary. I assume this is because it wasn't necessary rather than doing so causes problems. Is it alright if I allow instantiation to let DialogFragment handle AlertDialogs during rotation?

Assuming you mean that instantiation of NativeLibrary is disallowed (I wasn't sure what you meant at first), then... I don't really see how allowing that would make sense. Could you explain further about in what way being able to create instances of NativeLibrary would help?

Sorry, still learning a lot of terminology here. I've made NativeLibrary extend DialogFragment. From what I've read, DialogFragment's dialog can be retained during orientation change by including a newInstance of the class.

In this case, I would use

  private static NativeLibrary newInstance(String title, String message, boolean yesNo)
  {
    NativeLibrary nativeLibrary = new NativeLibrary();

    Bundle args = new Bundle();
    args.putString(ARG_TITLE, title);
    args.putString(ARG_MESSAGE, message);
    args.putBoolean(ARG_YES_NO, yesNo);
    nativeLibrary.setArguments(args);

    return nativeLibrary;
  }

...in NativeLibrary which is a problem if instantiation is disallowed. Allowing instantiation fixes this problem and (as far as I can tell) causes no additional problems. I just wanted to confirm that allowing instantiation would be fine.

If my terminology is still confusing, I can post a draft PR. I was hoping to fix my second question before doing so.

But why do you want to instantiate NativeLibrary instead of creating a new class that you can instantiate? My main problem with this is that making NativeLibrary inherit from DialogFragment doesn't make logical sense – the native library as a whole is not a dialog.

Creating a new class works, thanks! Now I just need to figure out how to get the lock object working with orientation changes.

Could you post a stack trace of what the UI thread is doing when you get the deadlock? Perhaps the problem is not with the msgAlert code itself, but with the emulation activity trying to do something like notifying the native library of a new surface.

No exception is thrown so I manually paused emulation. I'm not sure if this is relevant but after orientation change for the new class that extends DialogFragment, I can hit a breakpoint at onSaveInstanceState but the app is frozen before I can hit a breakpoint at onStop. setRetainInstance didn't seem to matter. I've yet to look into surfaces but let me know if that's what this stack trace indicates.

WaitUntilDoneBooting:-1, NativeLibrary (org.dolphinemu.dolphinemu)
clearSurface:389, EmulationFragment$EmulationState (org.dolphinemu.dolphinemu.fragments)
surfaceDestroyed:232, EmulationFragment (org.dolphinemu.dolphinemu.fragments)
updateSurface:621, SurfaceView (android.view)
windowStopped:220, SurfaceView (android.view)
setWindowStopped:1283, ViewRootImpl (android.view)
setStoppedState:611, WindowManagerGlobal (android.view)
performStop:7144, Activity (android.app)
performDestroyActivity:4395, ActivityThread (android.app)
handleDestroyActivity:4456, ActivityThread (android.app)
handleRelaunchActivity:4730, ActivityThread (android.app)
-wrap18:-1, ActivityThread (android.app)
handleMessage:1599, ActivityThread$H (android.app)
dispatchMessage:105, Handler (android.os)
loop:164, Looper (android.os)
main:6541, ActivityThread (android.app)
invoke:-1, Method (java.lang.reflect)
run:240, Zygote$MethodAndArgsCaller (com.android.internal.os)
main:767, ZygoteInit (com.android.internal.os)

Yep, that's the emulation activity getting a deadlock when trying to notify the native library of a surface change. That's annoying... Though on the other hand, if I'm understanding this deadlock correctly, it only happens if we get a msgAlert while the core is in the process of booting.

...And I thought this was going to be a simple fix. I'll read up on surfaces and return to this at some point in the future. Thanks again!

I believe if a msgAlert happened when the core was in the process of booting, we'd dereference a nullptr when the surface is destroyed due to EmulationFragment.clearSurface. Instead we get a deadlock so I don't think this only happens if we get a msgAlert while the core is in the process of booting.