[Bug 33275] New: Far Cry: Segmentation Fault on start
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(a)winehq.org ReportedBy: ascendant512(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=33275 --- Comment #1 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Please attach a standard console log unless otherwise instructed. -- 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=33275 Antonio López <amlopezalonso(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amlopezalonso(a)gmail.com --- Comment #2 from Antonio López <amlopezalonso(a)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. -- 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=33275 --- Comment #3 from Luis Alvarado <luisalvaradox(a)gmail.com> --- I can confirm this bug with 1.7.13 using Ubuntu 12.10 32 Bit and 13.10 64 bit. -- 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=33275 --- Comment #4 from Luis Alvarado <luisalvaradox(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression --- Comment #5 from Austin English <austinenglish(a)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 -- 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=33275 --- Comment #6 from Antonio López <amlopezalonso(a)gmail.com> --- While performing a regression test, I'm getting segfaults even in versions supposed to work fine like 1.4.1. Any idea? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #7 from Austin English <austinenglish(a)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. -- 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=33275 Roland Haeder <roland(a)mxchange.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roland(a)mxchange.org --- Comment #8 from Roland Haeder <roland(a)mxchange.org> --- Still there with latest GIT/master. -- 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=33275 Shmerl <shtetldik(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shtetldik(a)gmail.com --- Comment #9 from Shmerl <shtetldik(a)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. -- 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=33275 --- Comment #10 from Luis Alvarado <luisalvaradox(a)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. -- 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=33275 hanska2(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2(a)luukku.com --- Comment #11 from hanska2(a)luukku.com --- Please add recent debug log as attachment with recent wine. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #12 from Sebastian Lackner <sebastian(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #13 from Shmerl <shtetldik(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael(a)fds-team.de -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #14 from Sebastian Lackner <sebastian(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Anastasius Focht <focht(a)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(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #16 from Sebastian Lackner <sebastian(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #17 from Sebastian Lackner <sebastian(a)fds-team.de> --- Patch was submitted and is currently waiting for review: https://patchwork.kernel.org/patch/4977121/ -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #18 from Shmerl <shtetldik(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #19 from Sebastian Lackner <sebastian(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #20 from Sebastian Lackner <sebastian(a)fds-team.de> --- Oops, third line should be: sudo modprobe msr -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #21 from Sebastian Lackner <sebastian(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 mrdeathjr28(a)yahoo.es changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28(a)yahoo.es -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #22 from Shmerl <shtetldik(a)gmail.com> --- So what kernel release do you expect to include this patch? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #23 from Sebastian Lackner <sebastian(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #24 from Sebastian Lackner <sebastian(a)fds-team.de> --- The fix is included in 3.18-rc3. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Łukasz Janowski <fuorviatos(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fuorviatos(a)gmail.com --- Comment #25 from Łukasz Janowski <fuorviatos(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #26 from Bruno Jesus <00cpxxx(a)gmail.com> --- Can we close UPSTREAM? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #27 from Austin English <austinenglish(a)gmail.com> --- (In reply to Bruno Jesus from comment #26)
Can we close UPSTREAM?
Yes, -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #28 from Austin English <austinenglish(a)gmail.com> --- Fixed UPSTREAM > closing. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Eneko <enekonieto(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |enekonieto(a)gmail.com --- Comment #29 from Eneko <enekonieto(a)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! -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #30 from mrdeathjr28(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #31 from Eneko <enekonieto(a)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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #32 from mrdeathjr28(a)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) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #33 from mrdeathjr28(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|UPSTREAM |--- --- Comment #34 from Sebastian Lackner <sebastian(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69(a)gmail.com --- Comment #35 from Béla Gyebrószki <gyebro69(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #36 from Béla Gyebrószki <gyebro69(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 --- Comment #37 from mrdeathjr28(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #38 from joaopa <jeremielapuree(a)yahoo.fr> --- Can this bug be closed again as UPSTREAM, since the 4.4.0 kernel has the fix. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #39 from Austin English <austinenglish(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=33275 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |NOTOURBUG Status|RESOLVED |CLOSED --- Comment #40 from Austin English <austinenglish(a)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 -- 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)
-
wine-bugs＠winehq.org