Emulator

Is there a way to reproduce the issue? Will probably remove from current if there's not a real way to reproduce.

Unplug the GC Adapter while playing a game. I was playing multiplayer games. Just unplug it a few times and eventually when plugging it back in it'll crash.

Makes sense, can this be traced back to a particular build?

What exactly does cause the crashes now? Unplugging or plugging back in?

If it's plugging back in, is it a certain number of times you need to unplug and replug? Does work, if you wait 30 seconds when unplugging, before plugging it back in?

Can you post log output for this issue? There seems to be some logging to events around this, like "GC Adapter detached" or "Found GC Adapter with Vendor: %X Product: %X Devnum: %d".

Maybe this log out helps to narrow down what is going wrong. I don't have one of those adapters, so i can't test this myself.

And just to sure, on irc you said it's more likely to crash, when you unplug and plug in quickly?

I tried plugging and unplugging at least 40 times. No crash, input worked fine. Did it in melee and toadstool tour. Was anyone else able to reproduce this?

I couldn’t as well (on linux, trying both the hotplug and the polling thread path)

Wait, unplugging the controller from the adapter, or unplugging the adapter from usb?

Reproduced on my first try. Here is a Stack Trace:

>	Dolphin.exe!windows_cancel_transfer(usbi_transfer * itransfer) Line 2180	C
 	Dolphin.exe!libusb_cancel_transfer(libusb_transfer * transfer) Line 1494	C
 	Dolphin.exe!sync_transfer_wait_for_completion(libusb_transfer * transfer) Line 49	C
 	Dolphin.exe!do_sync_bulk_transfer(libusb_device_handle * dev_handle, unsigned char endpoint, unsigned char * buffer, int length, int * transferred, unsigned int timeout, unsigned char type) Line 181	C
 	Dolphin.exe!libusb_interrupt_transfer(libusb_device_handle * dev_handle, unsigned char endpoint, unsigned char * data, int length, int * transferred, unsigned int timeout) Line 307	C
 	Dolphin.exe!GCAdapter::ResetRumble() Line 455	C++
 	Dolphin.exe!GCAdapter::AddGCAdapter(libusb_device * device) Line 310	C++
 	Dolphin.exe!GCAdapter::Setup() Line 197	C++
 	Dolphin.exe!GCAdapter::ScanThreadFunc() Line 119	C++
 	Dolphin.exe!std::_LaunchPad<std::unique_ptr<std::tuple<void (__cdecl*)(void)>,std::default_delete<std::tuple<void (__cdecl*)(void)> > > >::_Run(std::_LaunchPad<std::unique_ptr<std::tuple<void (__cdecl*)(void)>,std::default_delete<std::tuple<void (__cdecl*)(void)> > > > * _Ln) Line 247	C++
 	Dolphin.exe!std::_Pad::_Call_func(void * _Data) Line 210	C++
 	ucrtbase.dll!_crt_at_quick_exit()	Unknown
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

Looks like a race condition.

I think Reset() is being called from the cpu thread to tear down the old connection to the gamecube adapter while the adapter scanning thread is in the middle of creating the new connection to the adapter.

I think the race condition is triggered by the ResetRumble() command at the tail end of of adapter initialization, somebody got a bit overzelious in PR 3244