[Bug 59851] New: Elite: Dangerous: crash/black screen upon opening game
http://bugs.winehq.org/show_bug.cgi?id=59851 Bug ID: 59851 Summary: Elite: Dangerous: crash/black screen upon opening game Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: quasarhasanewemail@proton.me Distribution: Gentoo Created attachment 81149 --> http://bugs.winehq.org/attachment.cgi?id=81149 terminal paste When not using WINE_D3D_CONFIG='renderer=vulkan', the game crashes after pressing the "launch" button on the game launcher. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59851 quasar quasar <quasarhasanewemail@proton.me> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81149|0 |1 is obsolete| | --- Comment #1 from quasar quasar <quasarhasanewemail@proton.me> --- Created attachment 81151 --> http://bugs.winehq.org/attachment.cgi?id=81151 game terminal crash output -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59851 kolAflash <kolAflash@kolahilft.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kolAflash@kolahilft.de --- Comment #2 from kolAflash <kolAflash@kolahilft.de> --- Do I assume correctly that these three bugs are related? winetricks -q dotnet472 crashes wineserver, too many open files. https://bugs.winehq.org/show_bug.cgi?id=59852 Elite: Dangerous: crashes on launch with ntsync and a low ulimit -Hn https://bugs.winehq.org/show_bug.cgi?id=59853 I understood these other bug reports in a way, that only the hard limit on open files (-Hn) is relevant. Correct? . The current distros Debian-13 (stable), Debian-14 (testing/beta) and Fedora-44 all have the following limits. soft (-S): 1024 # probably not relevant here hard (-H): 524288 I understood you in a way, that you're using the default hard limit by Gentoo? If yes, Gentoo maybe choose the limit a bit low. So you may ask Gentoo to raise the default limit. Or if Gentoo doesn't explicitly sets a limit, from which upstream component the limit is inherited - maybe Bash or the Linux kernel. On the other hand, as of now (June 2026) most distros don't seem to load ntsync by default. And as long as Gentoo doesn't do that, if may be considered the users job to raise the limit when manually loading ntsync. Maybe you should suggest Gentoo, to offer a package which autoloads ntsync and raises the hard limit altogether. Fedora-44 has a ntsync-autoload package. It just doesn't raise the limit (probably because Fedora-44 already has a hard limit of 524288). https://packages.fedoraproject.org/pkgs/wine/ntsync-autoload/ . The only thing I guess Wine could do, is to offer a better mechanism to notify the user if the limit has been hit. Mostly to document things properly: Can you check which hard limit is roughly needed (2^x) to make things work? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59851 --- Comment #3 from quasar quasar <quasarhasanewemail@proton.me> ---
Do I assume correctly that these three bugs are related?
nope! this bug is separate as I could replicate it with ulimit -Hn set in rc.conf to 1048576. Per https://bugs.winehq.org/show_bug.cgi?id=56250#c3, Brendan McGrath wanted to report that bug, but it was never done as far as I know. (In reply to kolAflash from comment #2)
I understood these other bug reports in a way, that only the hard limit on open files (-Hn) is relevant. Correct? yes! raising ulimit -Hn solves this, having a ulimit -Hn of 4096 while not having ntsync loaded also fixes this
I understood you in a way, that you're using the default hard limit by Gentoo? If yes, Gentoo maybe choose the limit a bit low. So you may ask Gentoo to raise the default limit. Or if Gentoo doesn't explicitly sets a limit, from which upstream component the limit is inherited - maybe Bash or the Linux kernel. I'm using the default gentoo limit, I'll try to file an issue with them or maybe change the gentoo wiki so that it is clearer that using ntsync means that you have to raise your ulimit -Hn
The only thing I guess Wine could do, is to offer a better mechanism to notify the user if the limit has been hit.
Mostly to document things properly: Can you check which hard limit is roughly needed (2^x) to make things work?
I can try, but I believe that Zebediah Figura's guidance on the issue is sufficient. Especially since the default Debian/Fedora limit is 1048576/2 https://github.com/ValveSoftware/wine/blob/b8fdff8e1f855b5276ec4ddca0f31b279... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59851 --- Comment #4 from kolAflash <kolAflash@kolahilft.de> --- (In reply to quasar quasar from comment #3)
Do I assume correctly that these three bugs are related?
nope! this bug is separate [...]as I could replicate it with ulimit -Hn set in rc.conf to 1048576. [...]
Bug #59853 makes it sound like the game works with a hard limit higher than 4096, even when the renderer is NOT vulkan. You may want to clarify that in bug #59853 Anyway, sorry for the confusion. Then lets move the open-file-ulimit discussion over there. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla