Yes, Mine too.. same error

System: https://gist.github.com/Kazenin/72414766b38275e0d016cefc3579247f
Log:
steam-524220.log

I have the same error

Same here. Keeps crashing every half hour or so.

Update! Turning off e-sync via launch options seems to have fixed the issue, still not sure if it can be called a permanent fix, but the game no longer crashes every half hour.

Sorry in advance, but even after reading the github entry, im still not sure how to do this.

1048576

But, when i turn off e-sync my fps goes severaly down

@kisak-valve My ulimit is 4096 and the game crashed a lot for me with this error. However since setting PROTON_NO_ESYNC=1 I haven't had a single crash for a few hours.

Can confirm setting PROTON_NO_ESYNC=1 completely fixes stability issues for me. Had been crashing every 15-30 mins or so. After taking a shot in the dark with disabling ESYNC, I'm 20+ hours with zero crashes.

Performance is very good and seems to be identical to without disabling of ESYNC. Arch, kernel 4.18.9, Cinnamon, nvidia gtx980 (396.54)

As I understand it, the windows port of this game is plagued by stability, fullscreen and performance issues natively under windows, so I don't think this is an entirely Wine/Proton issue. There is a mod called FAR which seems to fix these same frequent CTDs for most people and is considered necessary for a good experience. Interestingly, the display/fullscreen problem is already fixed for Linux users by Proton/DXVK lol.

Honestly, if I'm having trouble with a game under Proton, the first thing I do is disable ESYNC. This often fixes the problem (Nier, Bioshock 1 and 2 remastered, Gauntlet, etc.)

I understand what the ESYNC patch is attempting to do, but still feel that the wineserver is a more appropriate host for IO given the structure of Wine. I think it might be a good idea to disable it by default or remove it from the Proton patchset.

The stability loss for near-zero performance gain (in my experience) does not seem worth it.

@SeeK-ntr0py although, it does seem to have some crazy input lag that isn't there on windows, though that has been a problem for most games iv'e tried so far.

I have a workaround for crash issue:

1 - Edit the file /etc/security/limits.conf by adding at the end of it the option * hard nofile 1048576
2 - Edit the files /etc/systemd/system.conf and /etc/systemd/user.conf by adding at the end of these files the option DefaultLimitNOFILE=1048576
3 - run the command sudo systemctl daemon-reexec and restart your session
4 - Open the terminal and run ulimit -Hn. If all is correct, you will see 1048576

The explanation is here

@Kazenin disabling ESYNC in step 5 renders steps 1-4 moot. Those would only serve as dirty hacks related to the use of the ESYNC patch, which is much easier to disable.

Also, editing system-wide (particularly systemd and security) configuration files is not only unnecessary, but highly inadvisable for a many reasons and implications. It's absolutely beyond scope for Proton to modify system files as any form of solution or workaround. The esync patch has not been accepted yet into mainline wine or wine-staging for good reasons :)

I can confirm that increasing file descriptor limit works. After enabling ESYNC again and increasing file descriptor limit to 1048576 the game also stopped crashing.

If your distribution is using systemd, which most are these days, the best way to set it higher is to drop a file into /etc/systemd/system.conf.d with any name ending in .conf, for example limit.conf, with the following two lines:

[Manager]
DefaultLimitNOFILE=1048576

@SeeK-ntr0py I think it's perfectly reasonable to require a little configuration if it increases performance. It should just be documented and perhaps not enabled by default if it can't be automated.

@iroedius Simply, no. It is out of scope for a userspace game client such as Steam/Proton to require changes to be made to systemd configuration.

The issue needs to be corrected in the userspace application, which, by definition, needs to function within OS specifications. If it cannot do so with regard to functionality or stability then it is to be considered bugged.

Enabling or automating this on Valve's side would require Steam to run with root level access which -- for reasons which I hope are obvious event to bacteria -- has completely unacceptable security implications. This is just a Wine fork, not kernel/systemd development =)

@SeeK-ntr0py I agree that in this case automation is out of the question, since it requires root privileges and alters the behavior of the whole OS. Instead, until ESYNC is fixed to work for all games with no changes to system configuration, it should be disabled by default, a variable added to enable it and the required changes to system configuration on the user part documented. If it can increase performance it should definitely be an option.

@iroedius

until ESYNC is fixed to work for all games with no changes to system configuration, it should be disabled by default, a variable added to enable it and the required changes to system configuration on the user part documented. If it can increase performance it should definitely be an option.

Totally agree with you; this seems like the right solution at this time.

@Kazenin disabling ESYNC in step 5 renders steps 1-4 moot. Those would only serve as dirty hacks related to the use of the ESYNC patch, which is much easier to disable.

Also, editing system-wide (particularly systemd and security) configuration files is not only unnecessary, but highly inadvisable for a many reasons and implications. It's absolutely beyond scope for Proton to modify system files as any form of solution or workaround. The esync patch has not been accepted yet into mainline wine or wine-staging for good reasons :)

Sorry, I made a huge mistake. Thanks for read and answer