GCAdapter: Defer initialization until MainWindow::InitControllers

[Pokechu22]

If libusb fails to initialize, an assertion fails, but if that happens before the main window is created, then Dolphin just dies. Now, the panic alert is properly shown and the user can ignore it.

Note that the shutdown still happens in UICommon:

dolphin/Source/Core/UICommon/UICommon.cpp

Lines 118 to 126 in 58c02e6

	void Shutdown()
	{
	GCAdapter::Shutdown();
	WiimoteReal::Shutdown();
	Common::Log::LogManager::Shutdown();
	Discord::Shutdown();
	SConfig::Shutdown();
	Config::Shutdown();
	}

(Wiimote::Shutdown is called in MainWindow::ShutdownControllers, but WiimoteReal::Shutdown is in UICommon, so I think it's fine to have it organized like this... though I'm not fully sure.)

[leoetlino]

I believe this would break GCAdapter for DolphinNoGUI, since GCAdapter::Init is only called from DolphinQt with this change.

Edit: This is probably why FifoCI fails.

[Pokechu22]

Changed by adding a call in MainNoGUI.cpp. But now I'm not sure if this works on android (though I don't know if it's even possible to use a GC adapter on android, though that's tangential to whether GCAdapter is initialized on it).

Note that this means that dolphin-emu-nogui does still suffer from the same abort() call if libusb fails to initialize. I don't think it ever registers a custom panic handler, though, so deferring initialization wouldn't change this.

[JosJuice]

GCAdapter is fully supported on Android. Please add a call inside Java_org_dolphinemu_dolphinemu_NativeLibrary_Initialize in MainAndroid.cpp.

[pizuz]

EDIT: Sorry, this post was pretty confusing. I was referring to mainline Dolphin from the beginning.

Hi,
dunno if whatever was fixed in ProjectRio, might be also present in Dolphin mainline. Anyway, I'm getting a freeze on macOS since this PR. To be more specific: As soon as I press the close button, Dolphin freezes. I made a core dump, attached below:

dolphin_crash.txt

Shall I file a separate bug report?

[Pokechu22]

If you can reproduce on mainline dolphin, please do file a bug report. (Here's the version with this change, and the version immediately before without this change).

I don't know anything about ProjectRio, but it looks like they attempt to revert this commit: ProjectRio/ProjectRio@ef33152 (and have included that for a month). I'm not sure if their reversion is done correctly. If you can't reproduce it on mainline dolphin, this might be an issue with their reversion (or maybe it's fixed in their latest version with that reversion).

[pizuz]

I just saw that GitHub message. I have no idea what Project Rio is. This definitely affects mainline dolphin and I already bisected the issue.

Running and closing mainline Dolphin with the GCAdapter attached, produces the freeze starting this PR. Doing the same without it attached doesn't. Bug report filed here:

https://bugs.dolphin-emu.org/issues/12892

[shuffle2]

should this be moved after the next line? (Reset())

[Pokechu22]

We don't directly use the libusb context after this point, but I'm not knowledgeable enough about libusb to say whether that would make a difference (and whether s_handle is still valid).

[shuffle2]

The reported "crash" isn't a crash, it's a deadlock:
GCAdapter::Reset() is hung in a join() call for thread 0xe61f56.
thread 0xe61f56 is in poll() (either Read or Write threadfunc). Read/Write wrap libusb_interrupt_transfer.

LibusbUtils::Context::Impl::~Impl will have already killed it's EventThread and called libusb_interrupt_event_handler and libusb_exit. So..i think that's probably the problem.

[shuffle2]

@pizuz can you also try this change? (See my first comment)

[pizuz]

This produces a segfault:

dolphin_segfault.txt

I'll try your new PR next.

[shuffle2]

ok, that might have been fixed by one of the recent commits to libusb. so if you compile new PR yourself, make sure to git submodule update to include that part of PR

[pizuz]

I commented there. I tried the buildbot build of that PR.