[Bug 33275] Far Cry: Segmentation Fault on start
wine-bugs at winehq.org
wine-bugs at winehq.org
Tue Sep 16 15:00:59 CDT 2014
https://bugs.winehq.org/show_bug.cgi?id=33275
Sebastian Lackner <sebastian at fds-team.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sebastian at fds-team.de
--- Comment #12 from Sebastian Lackner <sebastian at 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.
More information about the wine-bugs
mailing list