You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently experiencing hard crashes when using Xenia Canary Netplay on Proton, whenever searching for a SystemLink match or when another client attempts to join a SystemLink match.
Not sure correct process. Happy to create my own PR, but assume changes like this are only pull from downstream Wine.
This is due to WSARecvFrom being provided an extremely large lpFromlen, as a placeholder until sockaddr_from_unix provides the correct value. The large value then overwriting data on the heap and crashes the application, before the correct addrlen value can be provided.
As the commits says; this is an application bug, but on Windows the From socket addr and addrlen are written to with the require data within the WSARecvFrom call and thus should be fixed here.
Removing memset( wsaddr, 0, wsaddrlen );, or changing it to memset( wsaddr, 0, sizeof(wsaddr) );, resolves the issues and allows SystemLink to function the same as windows.
Happy to provide more context if necessary.
The text was updated successfully, but these errors were encountered:
Currently experiencing hard crashes when using Xenia Canary Netplay on Proton, whenever searching for a SystemLink match or when another client attempts to join a SystemLink match.
tl;dr - require downsteam Wine commit to be pulled up to Proton to fix issue (specifically - https://gitlab.winehq.org/wine/wine/-/commit/d5bfa879088e7dfd3f79cdf724ce8f2880f872cb)
Not sure correct process. Happy to create my own PR, but assume changes like this are only pull from downstream Wine.
This is due to WSARecvFrom being provided an extremely large lpFromlen, as a placeholder until sockaddr_from_unix provides the correct value. The large value then overwriting data on the heap and crashes the application, before the correct addrlen value can be provided.
As the commits says; this is an application bug, but on Windows the From socket addr and addrlen are written to with the require data within the WSARecvFrom call and thus should be fixed here.
Removing
memset( wsaddr, 0, wsaddrlen );
, or changing it tomemset( wsaddr, 0, sizeof(wsaddr) );
, resolves the issues and allows SystemLink to function the same as windows.Happy to provide more context if necessary.
The text was updated successfully, but these errors were encountered: