http://bugs.winehq.org/show_bug.cgi?id=33275
Bug #: 33275 Summary: Far Cry: Segmentation Fault on start Product: Wine Version: 1.5.23 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: ascendant512@gmail.com Classification: Unclassified
Created attachment 44023 --> http://bugs.winehq.org/attachment.cgi?id=44023 Compressed relay debug log, use unxz or xz --decompress
When executing FarCry.exe, wine will segfault. This happens before the game finishes starting.
This is not a duplicate of http://bugs.winehq.org/show_bug.cgi?id=9252 The segfault happens before any Direct3D calls are made. I've attached the output of debug.err when running this script:
#!/bin/bash export WINEPREFIX=/mnt/media/bin/.wine/far_cry export WINEDEBUG="+relay,+d3d" wine "C:\Program Files (x86)\Far Cry\Bin32\FarCry.exe" 2> debug.err
Output of above is: ./farcry.bash: line 4: 24716 Segmentation fault wine "C:\Program Files (x86)\Far Cry\Bin32\FarCry.exe" 2> debug.err
This is of course a fresh wine prefix, no winetricks. Host OS: Gentoo amd64 wine compiled with these use flags: X alsa cups elibc_glibc gecko jpeg lcms mono mp3 ncurses nls opengl oss perl png prelink scanner ssl threads truetype udisks v4l win32 win64 xinerama xml -capi -custom-cflags -fontconfig -gphoto2 -gsm -gstreamer -ldap -odbc -openal -opencl -osmesa -pulseaudio -samba -selinux -test -xcomposite GCC version: 4.6.3
Game patched to version 1.4 with no-cd
http://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #1 from Ken Sharp imwellcushtymelike@gmail.com --- Please attach a standard console log unless otherwise instructed.
http://bugs.winehq.org/show_bug.cgi?id=33275
Antonio López amlopezalonso@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |amlopezalonso@gmail.com
--- Comment #2 from Antonio López amlopezalonso@gmail.com --- I'm confirming this bug in 1.7.12. The game crashes just after the splash screen (before any menu, etc.). Console only outputs segmentation fault.
Using Debian GNU/Linux Testing/Jessie (amd64) with NVIDIA GTX550Ti.
http://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #3 from Luis Alvarado luisalvaradox@gmail.com --- I can confirm this bug with 1.7.13 using Ubuntu 12.10 32 Bit and 13.10 64 bit.
http://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #4 from Luis Alvarado luisalvaradox@gmail.com --- Took my sweet time. This bug was not in Wine 1.4. It started in 1.7 or 1.6. The game works in 1.4.x
I have just tested 1.7.9, .10, .11, .12, .13 and .14. Same exact error in all of them.
https://bugs.winehq.org/show_bug.cgi?id=33275
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #5 from Austin English austinenglish@gmail.com --- (In reply to Luis Alvarado from comment #4)
Took my sweet time. This bug was not in Wine 1.4. It started in 1.7 or 1.6. The game works in 1.4.x
I have just tested 1.7.9, .10, .11, .12, .13 and .14. Same exact error in all of them.
Please run a regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #6 from Antonio López amlopezalonso@gmail.com --- While performing a regression test, I'm getting segfaults even in versions supposed to work fine like 1.4.1. Any idea?
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #7 from Austin English austinenglish@gmail.com --- (In reply to Antonio López from comment #6)
While performing a regression test, I'm getting segfaults even in versions supposed to work fine like 1.4.1. Any idea?
Perhaps something else is wrong with your system.
Please use the forums for help with debugging that.
http://bugs.winehq.org/show_bug.cgi?id=33275
Roland Haeder roland@mxchange.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roland@mxchange.org
--- Comment #8 from Roland Haeder roland@mxchange.org --- Still there with latest GIT/master.
http://bugs.winehq.org/show_bug.cgi?id=33275
Shmerl shtetldik@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shtetldik@gmail.com
--- Comment #9 from Shmerl shtetldik@gmail.com --- I think it started coring after some kernel update to me, even without changes in Wine (while Wine was still 1.4.x), so it's very probable that it's some kind of change the kernel that caused it.
http://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #10 from Luis Alvarado luisalvaradox@gmail.com --- Confirming bug in 1.7.22 This exactly happened to me in Ubuntu 11.10, 13.04, 13.10 and now 14.04 with several (At least 10) versions of Wine.
http://bugs.winehq.org/show_bug.cgi?id=33275
hanska2@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2@luukku.com
--- Comment #11 from hanska2@luukku.com --- Please add recent debug log as attachment with recent wine.
https://bugs.winehq.org/show_bug.cgi?id=33275
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #12 from Sebastian Lackner sebastian@fds-team.de --- Created attachment 49581 --> https://bugs.winehq.org/attachment.cgi?id=49581 WINEDEBUG=+tid,+seh,+loaddll,+int
I can confirm this issue.
I already tried to debug it some time ago, and at first also thought that its a regression - but regression testing didn't reveal anything useful, as the issue seems to be timing related. With older versions of wine it only happend with a probability of ~50%, but with wine 1.7.x it happens always. I cannot redo the testing right now, because older versions of Wine don't compile properly anymore on my distribution without additional patches to fix ./configure issues.
I assume this issue also only exists when running the CD-version (I have the original CD), I'm pretty sure its copy-protection related, so FarCry on Steam will most likely not suffer from the same issue. Installing the FarCry update 1.4 doesn't fix the problem. All logs in this bug report are with the update 1.4 installed, to avoid debugging issues which probably have been fixed in the game itself.
The weird part: The segmentation fault message is _not_ part of the debug log, its somehow written always on the terminal? The crash happens somewhere inside of the close() syscall, and it could even be a kernel bug?! I'll explain below what I've found out so far, and attach some logs. If someone wants to work on this issue and needs any additional information, feel free to ask me.
--- snip --- $ WINEDEBUG=+tid,+seh,+loaddll,+int WINEPREFIX=~/.wine-farcry/ ./wine ~/.wine-farcry/drive_c/Program\ Files/Ubisoft/Crytek/Far\ Cry/Bin32/FarCry.exe
~/Downloads/farcry_tid_seh_loaddll_int.log 2>&1
Speicherzugriffsfehler (Speicherabzug geschrieben) --- snip ---
The last message means translated "Segmentation fault (core dumped)".
Taking a look at the generated core dump reveals that at the time of crashing two threads were active:
--- snip --- (gdb) info thread Id Target Id Frame 2 Thread 0xf73b7700 (LWP 27874) 0xf77ead85 in __kernel_vsyscall () * 1 Thread 0x9afb40 (LWP 27920) segv_handler (signal=11, siginfo=0x7ffd3c8c, sigcontext=0x7ffd3d0c) at signal_i386.c:1957 (gdb) bt #0 segv_handler (signal=11, siginfo=0x7ffd3c8c, sigcontext=0x7ffd3d0c) at signal_i386.c:1957 #1 <signal handler called> #2 0xf77ead85 in __kernel_vsyscall () #3 0xf75d972f in close () from /usr/lib32/libpthread.so.0 #4 0x7bc850b6 in exit_thread (status=1) at thread.c:394 #5 0x7bc7e661 in call_thread_func_wrapper () at signal_i386.c:2578 #6 0x7bc7e69f in call_thread_func (entry=0x3650140a, arg=0x366224, frame=0x9aeb28) at signal_i386.c:2637 #7 0x7bc7e636 in call_thread_entry_point () at signal_i386.c:2578 #8 0x7bc85213 in start_thread (info=0x7ffd0fb8) at thread.c:429 #9 0xf75d2096 in start_thread () from /usr/lib32/libpthread.so.0 #10 0xf74f4a7e in clone () from /usr/lib32/libc.so.6 (gdb) thread 2 [Switching to thread 2 (Thread 0xf73b7700 (LWP 27874))] #0 0xf77ead85 in __kernel_vsyscall () (gdb) bt #0 0xf77ead85 in __kernel_vsyscall () #1 0xf75d96bb in read () from /usr/lib32/libpthread.so.0 #2 0x7bc77d76 in wait_select_reply (cookie=0x33e7dc) at server.c:335 #3 0x7bc78a56 in server_select (select_op=0x33e834, size=8, flags=2, timeout=0x0) at server.c:599 #4 0x7bc819eb in NtWaitForMultipleObjects (count=1, handles=0x33e990, wait_any=1 '\001', alertable=0 '\000', timeout=0x0) at sync.c:863 #5 0x7b86e10d in WaitForMultipleObjectsEx (count=1, handles=0x33eb0c, wait_all=0, timeout=4294967295, alertable=0) at sync.c:188 #6 0x7b86df1b in WaitForSingleObject (handle=0xbc, timeout=4294967295) at sync.c:128 #7 0x3650227f in ?? () #8 0x000000bc in ?? () #9 0xffffffff in ?? () #10 0x00000000 in ?? () --- snip ---
Disassembling the block which caused the segmentation fault:
--- snip --- (gdb) x/10i 0xf77ead80 0xf77ead80 <__kernel_vsyscall>: push %ebp 0xf77ead81 <__kernel_vsyscall+1>: mov %ecx,%ebp 0xf77ead83 <__kernel_vsyscall+3>: syscall 0xf77ead85 <__kernel_vsyscall+5>: mov $0x2b,%ecx <---- 0xf77ead8a <__kernel_vsyscall+10>: mov %ecx,%ss 0xf77ead8c <__kernel_vsyscall+12>: mov %ebp,%ecx 0xf77ead8e <__kernel_vsyscall+14>: pop %ebp 0xf77ead8f <__kernel_vsyscall+15>: ret 0xf77ead90: sar $0xff,%cl 0xf77ead93: call *(%eax,%eax,1) -- snip ---
This means the segmentation fault was triggered by the kernel, not by an invalid memory access.
By taking a look at the TEB (derived from $ESP, like in the Wine source) of the crashed thread we can find out which of the threads triggered the crash (UniqueThread = 0x30):
--- snip --- (gdb) print *(TEB *)0x7ffd0000 $1 = {Tib = {ExceptionList = 0x9aea48, StackBase = 0x9b0000, StackLimit = 0x8b2000, SubSystemTib = 0x0, {FiberData = 0x0, Version = 0}, ArbitraryUserPointer = 0x0, Self = 0x7ffd0000}, EnvironmentPointer = 0x0, ClientId = {UniqueProcess = 0x8, UniqueThread = 0x30}, ActiveRpcHandle = 0x0, ThreadLocalStoragePointer = 0x0, Peb = 0x7ffdf000, LastErrorValue = 6, CountOfOwnedCriticalSections = 0, CsrClientThread = 0x0, Win32ThreadInfo = 0x0, Win32ClientInfo = {0 <repeats 31 times>}, WOW32Reserved = 0x0, CurrentLocale = 0, FpSoftwareStatusRegister = 0, SystemReserved1 = {0x0 <repeats 54 times>}, ExceptionCode = 0, ActivationContextStack = {Flags = 0, NextCookieSequenceNumber = 0, ActiveFrame = 0x0, FrameListCache = {Flink = 0x0, Blink = 0x0}}, SpareBytes1 = '\000' <repeats 23 times>, SystemReserved2 = {0x63, 0x6b, 0x0, 0x9aeb44, 0x12, 0x6, 0x14, 0x15, 0x0, 0x9afb40}, GdiTebBatch = {Offset = 0, HDC = 0x0, Buffer = { 10152744, 0 <repeats 309 times>}}, gdiRgn = 0x0, gdiPen = 0x0, gdiBrush = 0x0, RealClientId = {UniqueProcess = 0x0, UniqueThread = 0x0}, GdiCachedProcessHandle = 0x0, GdiClientPID = 0, GdiClientTID = 0, GdiThreadLocaleInfo = 0x0, UserReserved = {0, 0, 0, 0, 0}, glDispachTable = {0x0 <repeats 280 times>}, glReserved1 = {0x0 <repeats 26 times>}, glReserved2 = 0x0, glSectionInfo = 0x0, glSection = 0x0, glTable = 0x0, glCurrentRC = 0x0, glContext = 0x0, LastStatusValue = 3221225480, StaticUnicodeString = {Length = 0, MaximumLength = 522, Buffer = 0x7ffd0c00}, StaticUnicodeBuffer = {0 <repeats 261 times>}, DeallocationStack = 0x8b0000, TlsSlots = { 0x0, 0x12da10, 0x0 <repeats 62 times>}, TlsLinks = {Flink = 0x0, Blink = 0x0}, Vdm = 0x0, ReservedForNtRpc = 0x0, DbgSsReserved = {0x0, 0x0}, HardErrorDisabled = 0, Instrumentation = {0x0 <repeats 16 times>}, WinSockData = 0x0, GdiBatchCount = 0, Spare2 = 0, Spare3 = 0x0, Spare4 = 0x0, ReservedForOle = 0x0, WaitingOnLoaderLock = 0, Reserved5 = {0x0, 0x0, 0x0}, TlsExpansionSlots = 0x0, ImpersonationLocale = 0, IsImpersonating = 0, NlsCache = 0x0, ShimData = 0x0, HeapVirtualAffinity = 0, CurrentTransactionHandle = 0x0, ActiveFrame = 0x0, FlsSlots = 0x0} --- snip ---
It doesn't appear at all in the attached log, only when using some more verbose debugging flags (like +relay). Besides some weird string comparisons of the processor name, there is nothing which would explain why the close syscall crashes. Immediately after the crash of this thread the second thread in the process also crashes without ever returning from the read syscall, and the game exits. Commenting out the close(...) function calls in exit_thread() gets rid of the segmentation fault, but the application still terminates. Thanks to Michael for some suggestions and ideas, nevertheless the problem isn't really solved yet. If someone wants to take a look at this and needs more logs, feel free to ask.
Output from ProtectionId:
--- snip --- -=[ ProtectionID v0.6.5.5 OCTOBER]=- (c) 2003-2013 CDKiLLER & TippeX Build 31/10/13-21:09:09 Ready... Scanning -> C:\Program Files\Ubisoft\Crytek\Far Cry\Bin32\FarCry.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 1232572 (012CEBCh) Byte(s) -> File has 1170620 (011DCBCh) bytes of appended data starting at offset 0F200h [File Heuristics] -> Flag : 00000100000001001100000000000111 (0x0404C007) [Entrypoint Section Entropy] : 6.46 [Debug Info] Characteristics : 0x0 | TimeDateStamp : 0x406D9864 | MajorVer : 0 / MinorVer : 0 -> (0.0) Type : 2 -> CodeView | Size : 0x35 (53) AddressOfRawData : 0x65F0 | PointerToRawData : 0x4DF0 CvSig : 0x53445352 | SigGuid 1727C30E-3D32-45C4-BE7AEDE4E59292D5 Age : 0xC | Pdb : C:\MasterCD\Bin32\FarCry.pdb
[!] Safedisc v3.20.022 detected ! [i] Appended data contents.... [.] o: 0x0000F228 / t: <0xA8726B03> <0xEF01996C> <0x00000001> / s: 00206395 byte(s) -> ~de1633.tmp [.] o: 0x0004188A / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00011923 byte(s) -> clcd32.dll [.] o: 0x00044744 / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00004122 byte(s) -> clcd16.dll [.] o: 0x00045782 / t: <0xA8726B03> <0xEF01996C> <0x0000044D> / s: 00037971 byte(s) -> mcp.dll [.] o: 0x0004EBFC / t: <0xA8726B03> <0xEF01996C> <0x00000002> / s: 00006616 byte(s) -> SECDRV.SYS [.] o: 0x000505FB / t: <0xA8726B03> <0xEF01996C> <0x00000002> / s: 00014386 byte(s) -> DrvMgt.dll [.] o: 0x00053E56 / t: <0xA8726B03> <0xEF01996C> <0x0000000B> / s: 00005446 byte(s) -> SecDrv04.VxD [.] o: 0x000553C1 / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00059964 byte(s) -> ~e5.0001 [.] o: 0x00063E24 / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00028672 byte(s) -> PfdRun.pfd [.] o: 0x0006AE4C / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00794652 byte(s) -> ~df394b.tmp [CompilerDetect] -> Visual C++ 7.1 (Visual Studio 2003) - Scan Took : 0.550 Second(s) [000000226h tick(s)] [533 scan(s) done] --- snip ---
$ sha1sum ~/Downloads/far_cry_v1.4_cumulative.exe 97867730d746beec513464aa0bb30fd26ad1b2c3 /home/sebastian/Downloads/far_cry_v1.4_cumulative.exe
$ sha1sum ~/.wine-farcry/drive_c/Program\ Files/Ubisoft/Crytek/Far\ Cry/Bin32/FarCry.exe 102f23357f083df50b7a941490f5661472bda385 /home/sebastian/.wine-farcry/drive_c/Program Files/Ubisoft/Crytek/Far Cry/Bin32/FarCry.exe
$ git describe origin/master wine-1.7.26-60-g0fa8ae7
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #13 from Shmerl shtetldik@gmail.com --- (In reply to Sebastian Lackner from comment #12)
I assume this issue also only exists when running the CD-version (I have the original CD), I'm pretty sure its copy-protection related, so FarCry on Steam will most likely not suffer from the same issue.
GOG version of FarCry which is DRM-free, suffers from this crash as well.
https://bugs.winehq.org/show_bug.cgi?id=33275
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #14 from Sebastian Lackner sebastian@fds-team.de --- Ah, nice. Since it wasn't that expensive I just bought the GOG version, and I can indeed also reproduce the same issue. The big advantage of this version: No DRM and weird anti-debugging tricks, which (hopefully) allows to use some better tools to track this down.
When running without strace the crash happens on the thread termination (in the close syscall), as already mentioned in my previous message:
--- snip --- 003f:Starting thread proc 0x3650140a (arg=0x36661c) 003f:Call KERNEL32.GetPriorityClass(ffffffff) ret=365012ff 003f:Ret KERNEL32.GetPriorityClass() retval=00000020 ret=365012ff 003f:Call KERNEL32.GetThreadPriority(fffffffe) ret=36501311 003f:Ret KERNEL32.GetThreadPriority() retval=00000000 ret=36501311 [...] 003f:Call msvcr71.strncpy(00366694,0077e97c "AMD Phenom(tm) II X4 840 Processor",00000040) ret=36501c65 003f:Ret msvcr71.strncpy() retval=00366694 ret=36501c65 003f:Call msvcr71.strncat(00366694 "AMD Phenom(tm) II X4 840 Processor",3656a7f5 "",00000040) ret=36501c71 003f:Ret msvcr71.strncat() retval=00366694 ret=36501c71 [...] 003f:Call msvcr71._stricmp(0077e97c "AMD Phenom(tm) II X4 840 Processor",3656a608 "WinChip2") ret=36502180 003f:Ret msvcr71._stricmp() retval=ffffffea ret=36502180 [...] 003f:Call PE DLL (proc=0x7ed5c3c3,module=0x7ecb0000 L"user32.dll",reason=THREAD_DETACH,res=(nil)) 003f:Ret PE DLL (proc=0x7ed5c3c3,module=0x7ecb0000 L"user32.dll",reason=THREAD_DETACH,res=(nil)) retval=1 * crash * --- snip ---
When running with strace the crash happens earlier, shortly after the thread was created, but is very similar:
--- snip --- [pid 719] [f77e4d85] write(2, "003a:Starting thread proc 0x3650"..., 52003a:Starting thread proc 0x3650140a (arg=0x36661c) ) = 52 [pid 719] [f77e4d85] write(2, "003a:Call KERNEL32.GetPriorityCl"..., 59003a:Call KERNEL32.GetPriorityClass(ffffffff) ret=365012ff ) = 59 [pid 719] [f77e4d85] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- [pid 719] [7bc7d3a8] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- [pid 719] [????????????????] +++ killed by SIGSEGV (core dumped) +++ [????????????????] +++ killed by SIGSEGV (core dumped) +++ --- snip ---
Like in the case without running with strace there are two segment violations, the first one after the write syscall opcode, and the second address corresponds to the beginning of the segv_handler:
--- snip --- (gdb) bt #0 segv_handler (signal=11, siginfo=0x7ffd7c8c, sigcontext=0x7ffd7d0c) at signal_i386.c:1957 <---- second segfault #1 <signal handler called> #2 0xf77e4d85 in __kernel_vsyscall () <---- first segfault #3 0xf75d363b in write () from /usr/lib32/libpthread.so.0 #4 0x7bc39d60 in NTDLL_dbg_vprintf (format=0x7bca20ad ") ret=%08lx\n", args=0x77e884 "\377\022P6") at debugtools.c:147 #5 0xf760cd45 in wine_dbg_printf (format=0x7bca20ad ") ret=%08lx\n") at debug.c:223 #6 0x7bc67f95 in relay_trace_entry (descr=0x7b8bd5a0, idx=66091, stack=0x77e908) at relay.c:348 #7 0x7bc68180 in relay_call () at relay.c:378 #8 0x7b823119 in __wine_spec_relay_entry_points () from /home/sebastian/projects/wine/dlls/kernel32/kernel32.dll.so #9 0x365012ff in ?? () #10 0xffffffff in ?? () #11 0x0000000f in ?? () #12 0x0036661c in ?? () #13 0x3650169d in ?? () #14 0x0036671c in ?? () #15 0x7bc7e658 in call_thread_func_wrapper () at signal_i386.c:2578 #16 0x7bc7e69f in call_thread_func (entry=0x3650140a, arg=0x36661c, frame=0x77eb28) at signal_i386.c:2637 #17 0x7bc7e636 in call_thread_entry_point () at signal_i386.c:2578 #18 0x7bc85213 in start_thread (info=0x7ffd4fb8) at thread.c:429 #19 0xf75cc096 in start_thread () from /usr/lib32/libpthread.so.0 #20 0xf74eea7e in clone () from /usr/lib32/libc.so.6 --- snip ---
Please note that all registers (including segment registers) of the crashing thread seem to be set properly, so those instructions definitely shouldn't cause arbitrary segfaults. I guess it will be necessary to take a look at kernel code, to figure out under which situations close()/write() can cause such a critical segfault, and why strace modifies the behaviour.
This time tested with:
$ sha1sum ~/.wine-farcry-nodrm/drive_c/GOG\ Games/Far\ Cry/Bin32/FarCry.exe a227baecf56a75219511594048379cb11721749a /home/sebastian/.wine-farcry-nodrm/drive_c/GOG Games/Far Cry/Bin32/FarCry.exe
Since the kernel version could make a difference:
$ uname -a Linux dalek 3.16.2-1-ARCH #1 SMP PREEMPT Sat Sep 6 13:12:51 CEST 2014 x86_64 GNU/Linux
https://bugs.winehq.org/show_bug.cgi?id=33275
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=33275
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Status|UNCONFIRMED |NEW URL| |http://www.gamershell.com/d | |ownload_4929.shtml Ever confirmed|0 |1
--- Comment #15 from Anastasius Focht focht@gmx.net --- Hello folks,
thanks for "inviting" me here :) I took a brief look at this as I'm currently busy with other projects.
Looks like a Linux kernel bug to me -> upstream.
The game tries to determine the exact CPU type by executing various (legacy) checks. During the check for 80286 and 80386 CPU type, the nested task (NT) flag gets set along with I/O Privilege Level (IOPL, 2 bits) and some reserved bit (through 'popfw').
Upon syscall entry, the IOPL bits get cleared as configured through MSR_SYSCALL_MASK but the NT flag is not touched at all, getting propagated to task switching code.
Reduced test case:
--- snip --- /* Compile: gcc -m32 -o ntflag ntflag.c Run: while true ; do ./ntflag ; done */ #include <stdio.h>
int main () { asm volatile("pushfl \n\t" \ "pop %eax \n\t" \ "or $0x4000,%eax \n\t" \ "push %eax \n\t" \ "popfl \n\t"); printf("exit or segfault\n"); return 0; } --- snip ---
x86 syscall_init() MSR_SYSCALL_MASK should also include 'X86_EFLAGS_NT' to be safe from userspace injection.
$ sha1sum DemoFarCry.zip 65200be08d5deab0f25eed9bba915e8da374933e DemoFarCry.zip
$ du -sh DemoFarCry.zip 497M DemoFarCry.zip
$ wine --version wine-1.7.26-97-g2398124
Regards
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #16 from Sebastian Lackner sebastian@fds-team.de --- Hi Anastasius,
thanks for the nice analysis (as usual). :) You are right, patching the kernel gets rid of the segmentation fault in both FarCry and the testcase you provided.
I've attached the kernel patch and my compiled kernel (for Archlinux) containing the fix below.
https://dl.dropboxusercontent.com/u/21447213/arch-kernel-farcry/0001-Clear-X... https://dl.dropboxusercontent.com/u/21447213/arch-kernel-farcry/linux-3.16.3... https://dl.dropboxusercontent.com/u/21447213/arch-kernel-farcry/linux-docs-3... https://dl.dropboxusercontent.com/u/21447213/arch-kernel-farcry/linux-header...
SHA1SUMS: 3e5094eb379c86027903d071671b32229378fa92 0001-Clear-X86_FLAGS_NT-in-syscall_init-for-x86.patch d839f8806828a46ecddbe75029fc191eeca12e28 linux-3.16.3-2-x86_64.pkg.tar.xz 6ae5154f5cbcaf47e6209399f08b368a483c5ff4 linux-docs-3.16.3-2-x86_64.pkg.tar.xz 52fffbdeb6c689e1443e99531e7be2ae97dd284b linux-headers-3.16.3-2-x86_64.pkg.tar.xz
Regards, Sebastian
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #17 from Sebastian Lackner sebastian@fds-team.de --- Patch was submitted and is currently waiting for review: https://patchwork.kernel.org/patch/4977121/
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #18 from Shmerl shtetldik@gmail.com --- Came Linus and started swearing in the thread because of impatient comments - how predictable. On one hand he is right - why should it be accepted so quickly if it's not a critical bug? On the other hand I can understand why such tone of replies can discourage participation.
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #19 from Sebastian Lackner sebastian@fds-team.de --- Hack-script to fix this issue temporarily without recompiling the kernel on AMD CPUs (by Michael Müller):
wget -O msr-fix.c http://ix.io/eyb gcc -o msr-fix msr-fix.c
sudo modprobe msr-fix sudo ./msr-fix
All changes will be gone after rebooting / going to suspend mode.
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #20 from Sebastian Lackner sebastian@fds-team.de --- Oops, third line should be:
sudo modprobe msr
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #21 from Sebastian Lackner sebastian@fds-team.de --- For those that didn't follow the kernel discussion closely: We're currently at revision 4 of this patch.
[1/2] https://patchwork.kernel.org/patch/5013961/ [2/2] https://patchwork.kernel.org/patch/5013971/
As the original patch doesn't fix all syscall paths, and as each change in this area might affect performance, there is a lot of discussion going on. ;)
For those that want to play the game in the meantime and are using an AMD processor, the trick by Michael Müller (comment 19) is the easiest solution. All others will have to compile a kernel with at least patch 1/2 from above applied. Patch 2/2 is optional, but might give some additional performance boost by reducing overhead for context switches.
https://bugs.winehq.org/show_bug.cgi?id=33275
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #22 from Shmerl shtetldik@gmail.com --- So what kernel release do you expect to include this patch?
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #23 from Sebastian Lackner sebastian@fds-team.de --- It will most probably be included in 3.18, and will probably also be backported for older kernel versions. Not sure about the exact schedule though.
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #24 from Sebastian Lackner sebastian@fds-team.de --- The fix is included in 3.18-rc3.
https://bugs.winehq.org/show_bug.cgi?id=33275
Łukasz Janowski fuorviatos@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fuorviatos@gmail.com
--- Comment #25 from Łukasz Janowski fuorviatos@gmail.com --- Guys,
thanks for tracking and fixing that. Just for your knowledge ; the steam version is affected as well. Waiting for the patched kernel to be released in Ubuntu.
Cheers
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #26 from Bruno Jesus 00cpxxx@gmail.com --- Can we close UPSTREAM?
https://bugs.winehq.org/show_bug.cgi?id=33275
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |UPSTREAM
--- Comment #27 from Austin English austinenglish@gmail.com --- (In reply to Bruno Jesus from comment #26)
Can we close UPSTREAM?
Yes,
https://bugs.winehq.org/show_bug.cgi?id=33275
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #28 from Austin English austinenglish@gmail.com --- Fixed UPSTREAM > closing.
https://bugs.winehq.org/show_bug.cgi?id=33275
Eneko enekonieto@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |enekonieto@gmail.com
--- Comment #29 from Eneko enekonieto@gmail.com --- Hi, problem persists in Kubuntu 15.04 with kernel 3.19 and latest wine.
$ uname -a Linux eneko 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:16:45 UTC 2015 i686 i686 i686 GNU/Linux
$ wine --version wine-1.7.38
$ wine FarCry.exe Illegal instruction (core dumped)
Have tried different no-cd fixes but I think all are the same (32 KB FarCry.exe).
I know bug is closed but I would want to know if patch to kernel was accepted. Last information said it should be accepted in 3.18RC3
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #30 from mrdeathjr28@yahoo.es --- In my case works
System specs
Nvidia Drivers 346.47 Linux Mint 17 XFCE Edition 64Bit - Kernel 3.18.0.31 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/) CPU: INTEL Pentium G3220 (Haswell 22nm) 3.0Ghz (Dual-Core) Stock Clock MEM: 8GB DDR3 1333 (2x4) Patriot value (128 bit dual channel: 21.3 gb/s) GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s) BOARD: MSI H81M E33
Gameplay Video
https://www.youtube.com/watch?v=SOEOXVH3Y28
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #31 from Eneko enekonieto@gmail.com --- (In reply to mrdeathjr28 from comment #30)
In my case works
System specs
Nvidia Drivers 346.47 Linux Mint 17 XFCE Edition 64Bit - Kernel 3.18.0.31 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/) CPU: INTEL Pentium G3220 (Haswell 22nm) 3.0Ghz (Dual-Core) Stock Clock MEM: 8GB DDR3 1333 (2x4) Patriot value (128 bit dual channel: 21.3 gb/s) GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s) BOARD: MSI H81M E33
Gameplay Video
Watching you run the game from steam I suppose you are not using any no-cd patch, are you?
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #32 from mrdeathjr28@yahoo.es --- (In reply to Eneko from comment #31)
(In reply to mrdeathjr28 from comment #30)
In my case works
System specs
Nvidia Drivers 346.47 Linux Mint 17 XFCE Edition 64Bit - Kernel 3.18.0.31 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/) CPU: INTEL Pentium G3220 (Haswell 22nm) 3.0Ghz (Dual-Core) Stock Clock MEM: 8GB DDR3 1333 (2x4) Patriot value (128 bit dual channel: 21.3 gb/s) GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s) BOARD: MSI H81M E33
Gameplay Video
Watching you run the game from steam I suppose you are not using any no-cd patch, are you?
yes i use steam version without nocd/dvd
More later upload new video with wine and nvidia drivers in use (1.7.39 + 349.12)
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #33 from mrdeathjr28@yahoo.es --- New gameplay video with wine 1.7.39 + Nvidia 349.12
https://www.youtube.com/watch?v=txEirN4JLmo
Nvidia Drivers 349.12 Linux Mint 17 XFCE Edition 64Bit - Kernel 3.18.0.31 CPU: INTEL Pentium G3220 (Haswell 22nm) 3.0Ghz (Dual-Core) Stock Clock MEM: 8GB DDR3 1333 (2x4) Patriot value (128 bit dual channel: 21.3 gb/s) GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s) BOARD: MSI H81M E33
https://bugs.winehq.org/show_bug.cgi?id=33275
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|UPSTREAM |---
--- Comment #34 from Sebastian Lackner sebastian@fds-team.de --- The problem is still present on AMD CPUs when using a pure 32-bit kernel. The following rebased kernel patch and Wine patch fixes it:
* kernel patch: http://ix.io/jPy * wine patch: http://ix.io/jPB
Please note that the kernel devs will most likely prefer a different solution (adding a check at the beginning of the syscall entry, similar to x86_64). This will make the wine patch unnecessary. I'll write something on the kernel mailing list shortly.
https://bugs.winehq.org/show_bug.cgi?id=33275
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #35 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Sebastian Lackner from comment #34)
The problem is still present on AMD CPUs when using a pure 32-bit kernel. The following rebased kernel patch and Wine patch fixes it:
- kernel patch: http://ix.io/jPy
- wine patch: http://ix.io/jPB
Please note that the kernel devs will most likely prefer a different solution (adding a check at the beginning of the syscall entry, similar to x86_64). This will make the wine patch unnecessary. I'll write something on the kernel mailing list shortly.
I confirm that the 2 patches fix the startup problem in FarCry (GOG.com version) when running a 32-bit kernel on my AMD Athlon64 X2 (fam: 0f, model: 6b, stepping: 02) cpu.
wine-1.7.47-118-ga90592c Fedora 22 32-bit Kernel 4.1.2
https://bugs.winehq.org/show_bug.cgi?id=33275
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #36 from Béla Gyebrószki gyebro69@gmail.com --- Far Cry v1.40 (GOG.com) still segfaults on start when running Linux kernel 4.3.3 (32-bit, PAE), but the game starts properly in kernels 4.4-rc6 and 4.4.0. This must have been fixed somewhere in the kernel tree.
Wine 1.9.2
https://bugs.winehq.org/show_bug.cgi?id=33275
--- Comment #37 from mrdeathjr28@yahoo.es --- In my case works with wine 1.9.2
System Specs
Nvidia Drivers 361.18 Linux Mint 17.2 Raffaela XFCE Edition 64Bit - Kernel 4.0.0-040000-generic (ubuntu mainline) CPU: INTEL Pentium G3258 (Haswell 22nm) 4.1Ghz + Artic Cooling Alpine 11 Plus MEM: 8GB DDR3 1333 (2x4) Patriot value (128 bit dual channel: 21.3 gb/s) GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s) BOARD: MSI H81M E33
Gameplay Video
https://www.youtube.com/watch?v=mO_bjJrIF3s
Maybe this problem have relation with amd cpus
https://bugs.winehq.org/show_bug.cgi?id=33275
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #38 from joaopa jeremielapuree@yahoo.fr --- Can this bug be closed again as UPSTREAM, since the 4.4.0 kernel has the fix.
https://bugs.winehq.org/show_bug.cgi?id=33275
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED
--- Comment #39 from Austin English austinenglish@gmail.com --- (In reply to joaopa from comment #38)
Can this bug be closed again as UPSTREAM, since the 4.4.0 kernel has the fix.
Thanks
https://bugs.winehq.org/show_bug.cgi?id=33275
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |NOTOURBUG Status|RESOLVED |CLOSED
--- Comment #40 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #39)
(In reply to joaopa from comment #38)
Can this bug be closed again as UPSTREAM, since the 4.4.0 kernel has the fix.
Thanks
Fixed in upstream release = closing