Project

General

Profile

Actions

Emulator Issues #12429

closed

DSU Controllers Get Broken After Ending Emulation

Added by tunsay about 3 years ago. Updated about 3 years ago.

Status:
Fixed
Priority:
High
Assignee:
-
% Done:

0%

Operating system:
Windows
Issue type:
Bug
Milestone:
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
5.0-13461
Fixed in:
5.0-13790

Description

Hello, I have a problem with DSU that I did not have with the others updated (before version 13500 I would say).
Everything is functional when I launch a game, the controller works perfectly, everything is recognized. But as soon as I start to close a game, DSU is no longer usable.

Actions #1

Updated by Miksel12 about 3 years ago

I recently noticed that after closing a game or fifolog for a second time, the log would start spamming: InputCommon\ControllerInterface\DualShockUDPClient\DualShockUDPClient.cpp:240 E[SI]: DualShockUDPClient HotplugThreadFunc send failed
Disabling and enabling the UDPClient doesn't fix it, restarting Dolphin seems to be the only solution. I haven't seen this befor so this seems to be recent regression.

Actions #2

Updated by JMC4789 about 3 years ago

If someone could figure out when this started, we could try to get it hotfixed.

Actions #3

Updated by Miksel12 about 3 years ago

5.0-12412 doesn't have the issue and is the latest DSU specific change. Don't have enough time to do more bisecting right now.

Actions #4

Updated by iwubcode about 3 years ago

Miksel12 wrote:

5.0-12412 doesn't have the issue and is the latest DSU specific change. Don't have enough time to do more bisecting right now.

Actually 5.0-13430 is the latest targeted change. Haven't done any testing to say if it's the issue though

Actions #5

Updated by Miksel12 about 3 years ago

5.0-13430 also has no issue.

Actions #6

Updated by Miksel12 about 3 years ago

I bisected it to 5.0-13461, I double checked as it seems completely unrelated but 5.0-13459 shows no weird behaviour.

Actions #7

Updated by JMC4789 about 3 years ago

My bisect ended up on 5.0-13430, which makes a lot more sense?

Unsure how you guys got a different bisect.

Actions #8

Updated by JMC4789 about 3 years ago

  • Subject changed from Problem witch DSU to DSU Controllers Get Permanently Broken After Ending Emulation Twice
  • Status changed from New to Accepted
  • Priority changed from Normal to High
  • Regression changed from No to Yes
  • Regression start set to 5.0-13430
Actions #9

Updated by filoppi about 3 years ago

It's actually enough to end the emulation once.
This should be fixed in my branch, there was a bunch of bad threads code.
https://github.com/dolphin-emu/dolphin/pull/9489
Unless it was broken after I last merged with master, but you said it was fine before 5.0-13430? Which was my first change to DSU.

Actions #10

Updated by JosJuice about 3 years ago

  • Subject changed from DSU Controllers Get Permanently Broken After Ending Emulation Twice to DSU Controllers Get Broken After Ending Emulation

Could you split out the fix? That is a very large PR.

Actions #11

Updated by filoppi about 3 years ago

No this problem doesn't happen neither on 5.0-13430 nor or 5.0-13428 on my machine, but it does happen on current latest. Though not on my build. So it could have been something in between the last time I merged with master that broke it. I will merge and try again as soon as I can, because there were a few fixes I made that could have helped with this.

Actions #12

Updated by JMC4789 about 3 years ago

I will test again if I have to, but I double checked this bisect because it collided with someone else's bisect.

Actions #13

Updated by JMC4789 about 3 years ago

  • Regression start deleted (5.0-13430)

Due to inconsistencies with the bug appearing, I'm no longer confident in my bisect. More people seem to be saying it doesn't occur in this build. It may be a race condition unrelated, but I still maintain that it can happen in that build.

Actions #14

Updated by Miksel12 about 3 years ago

I retested to be sure, 5.0-13430 and 5.0-13459 show no message in the log. 5.0-13461 does, always after closing a game for a second time. I didn't actually test if DSU worked or not but just looked at the log.

Actions #15

Updated by filoppi about 3 years ago

I've just updated my branch to master and this indeed has started happening. I'm gonna investigate tomorrow.

Actions #16

Updated by filoppi about 3 years ago

I can confirm the problem is here, in DualShockUDPClient.cpp:
if (server.m_socket.send(&list_ports, sizeof list_ports, server.m_address, server.m_port) != sf::Socket::Status::Done) ERROR_LOG_FMT(CONTROLLERINTERFACE, "DualShockUDPClient HotplugThreadFunc send failed");
that starts failing after we stop the emulation for the first time, but even if we comment out the code that calls PopulateDevices() when changing the dolphin main window, it will still break.
I've commented out pieces of code at random, tried to disable and re-enable the server, restarted DS4Windows, removed a server and added a new one with a new IP address. None of these worked.
It seems like UDP out communication is completely broken after emulation first stops, even if . The SMFL external (UDP) hasn't been changed in 7 months. The only other code that uses UDP is NetPlay and some wiimote stuff.

What is even more amazing is that if we start dolphin with DS4 UDP Client off, start the emulation, stop the emulation, then start the UDP Client, THE SOCKET SEND FUNCTION WILL STILL FAIL immediately!!!
Given that the UDP client thread isn't even started when it's off, and literally none of its code runs, it means this bug is NOT related to the DS4 UDP code, but to some other parts of Dolphin.
Possibly NetPlay does not uninitialize some stuff correctly? That doesn't really make sense I know, but it's really hard to make sense out of this, and the socket doesn't even send any specific error message. It just says ERROR.

This didn't happen before I merged with master, and I was on this commit: https://github.com/Filoppi/dolphin/commit/4cdcbb6ab28596653635ab91b1ccd0332629925a
So the breaking change must come between that, and ~9 days ago. Which isn't much honestly.

Actions #17

Updated by filoppi about 3 years ago

Can confirm the first broken version is 5.0-13461, commit:
https://github.com/dolphin-emu/dolphin/commit/59fa6130207a263718368999612a5fcb59d1c004
which does seem to mess with sockets. Will investigate.

Actions #19

Updated by JosJuice about 3 years ago

  • Status changed from Accepted to Fixed
  • Regression start set to 5.0-13461
  • Fixed in set to 5.0-13790
  • Operating system Windows added
  • Operating system deleted (N/A)
Actions

Also available in: Atom PDF