https://bugs.winehq.org/show_bug.cgi?id=45908
Bug ID: 45908 Summary: Eve Online frequently crashes with an unhandled page fault (fldl 0x0(%edx,%eax,8)) Product: Wine Version: 3.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: rafael.ristovski@gmail.com Distribution: ---
Created attachment 62432 --> https://bugs.winehq.org/attachment.cgi?id=62432 Wine backtrace
Eve Online frequently crashes with a page fault error, which seems to happen randomly _but only_ when the game is loading in-game structures/geometry (when undocking from a station or when loading space after a gate jump).
EVEs rendering engine appears to be using dynamic page allocation so no idea how to debug this. The full wine backtrace is attached.
The culprit seems to be the load float instruction which seems to load a 8-byte array (fld [edx+eax*8] - eax being the offset, and probably corrupting for some reason), as confirmed by the backtrace:
fldl 0x0(%edx,%eax,8)
I have tried debugging the graphics engine to find where this instruction is located but to no avail - maybe JIT?
The game does not produce any errors itself and just freezes, the wine debugger window opens shortly after that.
Tested with: All major Wine versions between 3.0 and 3.16.
https://bugs.winehq.org/show_bug.cgi?id=45908
Rafael Ristovski rafael.ristovski@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rafael.ristovski@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45908
Rafael Ristovski rafael.ristovski@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Rafael Ristovski rafael.ristovski@gmail.com --- This seems to have been an issue in libc, where running sin() with a specific value caused it to page fault. My current build of Wine did not report the full backtrace (I blame optimization levels), but using a binary wine build indeed produced the full backtrace. Resolved.
https://bugs.winehq.org/show_bug.cgi?id=45908
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #2 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=45908
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #3 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.
https://bugs.winehq.org/show_bug.cgi?id=45908
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal Status|RESOLVED |CLOSED
--- Comment #4 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Rafael Ristovski from comment #1)
This seems to have been an issue in libc, where running sin() with a specific value caused it to page fault. My current build of Wine did not report the full backtrace (I blame optimization levels), but using a binary wine build indeed produced the full backtrace. Resolved.
I gather the libc bug was fixed, correct?
https://bugs.winehq.org/show_bug.cgi?id=45908
--- Comment #5 from Rafael Ristovski rafael.ristovski@gmail.com --- (In reply to Matteo Bruni from comment #4)
(In reply to Rafael Ristovski from comment #1)
This seems to have been an issue in libc, where running sin() with a specific value caused it to page fault. My current build of Wine did not report the full backtrace (I blame optimization levels), but using a binary wine build indeed produced the full backtrace. Resolved.
I gather the libc bug was fixed, correct?
Yes, that is correct. Simply upgrading to a -RC version of libc seems to have fixed it. I suspect a weird edge case of the specific libc version and the compiler version (as my gcc is the latest version, more recent than in my distros repos)