http://bugs.winehq.org/show_bug.cgi?id=34367
Bug #: 34367 Summary: Freeze while playing Mass Effect 3 Product: Wine Version: 1.5.7 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: carlo.marchiori@gmail.com Classification: Unclassified
Created attachment 45748 --> http://bugs.winehq.org/attachment.cgi?id=45748 PlayOnLinux log file, which essentially wine log with some flag turned on.
I'm playing Mass Effect 3 on a
Hardware 64bit Card Radeon Cedar OpenGL renderer string: Gallium 0.4 on AMD CEDAR Debian Jessie/Sid testing distribution Wine 1.5.7
I've played the game for many days quite flawlessy and I've reached the point I'm seizing Cerberus Headquarters. Recently I've noticed some temporary freezes, and now a complete freeze. I cannot play the game beyond this point.
In the log I find errors such as
err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0055, blocked by 0066, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bcadc24 "loader.c: loader_section" wait timed out in thread 0066, blocked by 005a, retrying (60 sec)
It's quite sad not being able to finish the game at this point!!!
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #1 from Austin English austinenglish@gmail.com 2013-08-27 01:01:23 CDT --- Please retest in 1.7.0 using plain wine, not PlayOnLinux, it's not supported here.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #2 from Carlo Marchiori carlo.marchiori@gmail.com 2013-08-27 17:15:19 CDT --- I compiled wine 1.7.0 on my machine.
Mass Effect must be played through Origin, sort of Steam. Origin installation crashes. I attach the dump.
Running wine 1.7.0 on my existing WINEPREFIX where Origin was already installed, sends all my four CPU cores to 100% and there they remain.
Thanks, Carlo.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #3 from Carlo Marchiori carlo.marchiori@gmail.com 2013-08-27 17:16:25 CDT --- Created attachment 45755 --> http://bugs.winehq.org/attachment.cgi?id=45755 Origin setup crash log
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #4 from Carlo Marchiori carlo.marchiori@gmail.com 2013-08-27 18:57:03 CDT --- It's not that hopeless. I even played ME3 some minutes on wine 1.7.0. Everything appears unstable, because often cpus are sent steadily to 100%, sometimes the game crashes, but sometimes I get to playing.
Then again I stumbled upon the freeze with this same problem in the log:
err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0056, blocked by 006a, retrying (60 sec).
I'm available to perform further tests, if needed. Thanks, Carlo.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #5 from Carlo Marchiori carlo.marchiori@gmail.com 2013-08-28 15:26:44 CDT --- Created attachment 45764 --> http://bugs.winehq.org/attachment.cgi?id=45764 winedbg backtrace when cpus are sent to 100% (and there they remain)
Hello,
using winedbg I gathered a backtrace when Origin is sent to 100% cpu (and stays there).
I have obtained it by starting Origin with winedbg, sending a trap to the process and then issuing bt all command. If somebody can teach me how to obtain a better trace (for example with line numbers), I can do it.
Thanks, Carlo.
http://bugs.winehq.org/show_bug.cgi?id=34367
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #6 from Ken Thomases ken@codeweavers.com 2013-08-28 16:45:04 CDT --- Looks like an Xlib bug. I think it's a duplicate of bug 32859.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #7 from Carlo Marchiori carlo.marchiori@gmail.com 2013-08-28 16:57:55 CDT --- I also have libX11-1.6.1-1, apparently uptodate, then. Anyway there is some apparent form of memory curruption, since the game crashes or freezes randomly.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #8 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-02 09:52:08 CDT --- I have built Xorg server on my machine from git (version 1.14.2), but the problem is still there.
During compilation there are several builds that complain about unsafe casts.
So, either this problem with Origin is something else, or the bug 32859 is not actually fixed.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #9 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-02 20:13:37 CDT --- I have also built libX11, the client X11 library from git, but the problem is still there, so I think it isn't fixed after all.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #10 from Ken Thomases ken@codeweavers.com 2013-09-02 20:40:11 CDT --- The crash appears to be due to a bug in Xlib. It's not a Wine bug. Bug 32859 is closed "upstream" because the problem has to be fixed in another project on which Wine depends.
(Some people claimed certain crashes due to Xlib bugs were fixed by upgrades to Xlib, but apparently not all such Xlib bugs have been fixed.)
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #11 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-02 20:44:17 CDT --- I got the 100% cpu hotspot:
get_converter () at /home/carlo/Programmi/X/libX11/git/src/xlibi18n/lcConv.c:75 0x7e039bb2 get_converter+0xaf [/home/carlo/Programmi/X/libX11/git/src/xlibi18n/lcConv.c:75] in libx11.so.6: movl 0xfffffff4(%ebp),%eax 75 prev = list;
:-)
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #12 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-03 06:03:49 CDT --- Created attachment 45833 --> http://bugs.winehq.org/attachment.cgi?id=45833 After all I think it's a wine bug
Hello,
take a look at the attached stacktrace... ups... backtrace (oh my, yes, I'm a Java developer). I think it shows that after all it could be a problem with wine, or somewhere in between.
x11drv_init_thread_data sets up thread related information and ends up calling X11DRV_SetupXIM in libX11. But IM (Input Method) is coded statically, it saves IM state in static variables (global library scope) and, as far as I can see, it does it unprotected by locks.
winex11.drv/xim.c says
329 /*********************************************************************** 330 * X11DRV Ime creation 331 * 332 * Should always be called with the x11 lock held 333 */ 334 static BOOL open_xim( Display *display )
but is it?
http://bugs.winehq.org/show_bug.cgi?id=34367
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2013-09-03 06:50:10 CDT --- There's no X11 lock in Wine anymore. Xlib is supposed to protect its global data itself.
*** This bug has been marked as a duplicate of bug 34277 ***
http://bugs.winehq.org/show_bug.cgi?id=34367
Carlo Marchiori carlo.marchiori@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|DUPLICATE |
--- Comment #14 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-03 06:53:57 CDT --- I have disabled IM altogether.
It can be done setting the registry DWORD value
/HKCU/Software/Wine/X11 Driver/UseXIM = 0
And the crash is gone (not the bug though).
http://bugs.winehq.org/show_bug.cgi?id=34367
Carlo Marchiori carlo.marchiori@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |UPSTREAM
--- Comment #15 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-03 06:54:38 CDT --- Fine, so it's a bug of theirs.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #16 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-03 06:55:00 CDT --- Fine, so it's a bug of theirs.
http://bugs.winehq.org/show_bug.cgi?id=34367
Carlo Marchiori carlo.marchiori@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-03 16:04:31 CDT --- Closed, not resolved yet.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #18 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-14 14:22:43 CDT --- Created attachment 45959 --> http://bugs.winehq.org/attachment.cgi?id=45959 Backtrace gathered during freeze
All illegitimately blocked thread are hung calling RtlAllocateHeap. So is it a heap exaustion problem?
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #19 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-14 14:28:43 CDT ---
All illegitimately blocked thread are hung calling RtlAllocateHeap. So is it a heap exaustion problem?
Actually the game has allocated only 670MB (I have 4GB).
Carlo.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #20 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-14 14:45:23 CDT --- Of the 5 thread involved only one is (obviously) calling FindFreeBlock, and it doesn't return.
The system has plenty of free memory, so I think the FindFreeBlock has a bug, since there is no reason to hang.
http://bugs.winehq.org/show_bug.cgi?id=34367
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #21 from Dan Kegel dank@kegel.com 2013-09-14 16:59:31 CDT --- Does forcing single thread help (e.g. taskset -c1 wine ...) ?
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #22 from Ken Thomases ken@codeweavers.com 2013-09-15 02:11:07 CDT --- The freeze.txt file starts in the middle of a thread's backtrace, so there's some data that was lost from the start.
The threads getting stuck in the heap critical section suggests to me that either: a) a thread was unceremoniously terminated while holding that section, perhaps due to stack overflow; or b) there's a memory smashing bug that corrupted the critical section itself.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #23 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-15 07:27:53 CDT --- But one thread actually into the critical section and running HEAP_FindFreeBlock, and other four waiting on the critical section, doesn't suggest that the critical section is ok?
http://bugs.winehq.org/show_bug.cgi?id=34367
Carlo Marchiori carlo.marchiori@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|UPSTREAM |
--- Comment #24 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-15 07:43:22 CDT --- @Dan I've tried with tasksel, it freezes just the same.
Curiously, I've played the game through to 'Cerberus Headquarters" episode, meaning almost to the end. But here, ironically, it freezes in a deterministic fashion.
I reopen the bug because it was closed after resolution of a minor probem (IM static memory corruption), but the main problem (the freeze) is still open to investigation.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #25 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-15 08:25:50 CDT --- A tipicall thread backtrace looks like this. Anybody knows what are all those __clone+0x5d() lines in libc6 in the stack? And why so many? Just a curiosity.
Backtracing for thread 0056 in process 004f (C:\Program Files\Origin Games\Mass Effect 3\Binaries\Win32\Core\EACoreServer.exe): Backtrace: =>0 0xf779942e __kernel_vsyscall+0xe() in [vdso].so (0x007ee558) 1 0xf759272b __libc_read+0x4a() in libpthread.so.0 (0x007ee558) 2 0x7bc79328 wait_select_reply+0x57(cookie=0x7ee59c) [/home/carlo/Programmi/wine-1.7.1/dlls/ntdll/server.c:333] in ntdll (0x007ee558) 3 0x7bc7a0bb server_select+0x1ea(select_op=0x7ee6ac, size=0xc, flags=0x2, timeout=(nil)) [/home/carlo/Programmi/wine-1.7.1/dlls/ntdll/server.c:597] in ntdll (0x007ee678) 4 0x7bc81c78 NtWaitForMultipleObjects+0x77(count=0x2, handles=0x7ee810, wait_all=0, alertable=0, timeout=(nil)) [/home/carlo/Programmi/wine-1.7.1/dlls/ntdll/sync.c:835] in ntdll (0x007ee7b8) 5 0x7b871dc2 WaitForMultipleObjectsEx.part+0x131() in kernel32 (0x007ee928) 6 0x7b872038 WaitForMultipleObjectsEx+0x67() in kernel32 (0x007ee978) 7 0x7b87208b WaitForMultipleObjects+0x4a(count=<couldn't compute location>, handles=<couldn't compute location>, wait_all=<couldn't compute location>, timeout=<couldn't compute location>) [/home/carlo/Programmi/wine-1.7.1/dlls/kernel32/sync.c:148] in kernel32 (0x007ee9c8) 8 0x10218407 in eacore (+0x218406) (0x007eea18) 9 0x7bc7b120 call_thread_func_wrapper+0xb() in ntdll (0x007eea28) 10 0x7bc7e02d call_thread_func+0x7c(entry=0x10218340, arg=0x95d480, frame=0x7eeb18) [/home/carlo/Programmi/wine-1.7.1/dlls/ntdll/signal_i386.c:2602] in ntdll (0x007eeaf8) 11 0x7bc7b0fe call_thread_entry_point+0x11() in ntdll (0x007eeb18) 12 0x7bc83c5d start_thread+0xdc(info=0x7ffd4fb8) [/home/carlo/Programmi/wine-1.7.1/dlls/ntdll/thread.c:417] in ntdll (0x007ef368) 13 0xf758bcf1 start_thread+0xd0() in libpthread.so.0 (0x007ef468) 14 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 15 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 16 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 17 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 18 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 19 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 20 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 21 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 22 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 23 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 24 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 25 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 26 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 27 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 28 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 29 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 30 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 31 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 32 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 33 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 34 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 35 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 36 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 37 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 38 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 39 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 40 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 41 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 42 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 43 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 44 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 45 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 46 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 47 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 48 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 49 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 50 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 51 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 52 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 53 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 54 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 55 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 56 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 57 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 58 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 59 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 60 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 61 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 62 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 63 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 64 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 65 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 66 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 67 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 68 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 69 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 70 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 71 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 72 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 73 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 74 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 75 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 76 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 77 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 78 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 79 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 80 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 81 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 82 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 83 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 84 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 85 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 86 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 87 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 88 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 89 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 90 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 91 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 92 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 93 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 94 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 95 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 96 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 97 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 98 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 99 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 100 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 101 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 102 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 103 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 104 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 105 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 106 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 107 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 108 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 109 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 110 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 111 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 112 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 113 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 114 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 115 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 116 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 117 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 118 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 119 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 120 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 121 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 122 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 123 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 124 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 125 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 126 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 127 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 128 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 129 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 130 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 131 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 132 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 133 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 134 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 135 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 136 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 137 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 138 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 139 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 140 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 141 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 142 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 143 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 144 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 145 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 146 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 147 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 148 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 149 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 150 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 151 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 152 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 153 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 154 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 155 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 156 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 157 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 158 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 159 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 160 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 161 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 162 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 163 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 164 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 165 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 166 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 167 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 168 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 169 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 170 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 171 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 172 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 173 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 174 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 175 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 176 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 177 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 178 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 179 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 180 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 181 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 182 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 183 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 184 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 185 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 186 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 187 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 188 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 189 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 190 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 191 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 192 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 193 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 194 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 195 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 196 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 197 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 198 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 199 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000) 200 0xf74c3fee __clone+0x5d() in libc.so.6 (0x00000000)
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #26 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-15 09:23:00 CDT --- I have obtained other backtraces less consistent than the first (some threads waiting for the CriticalSection but no one into it), so Ken may be right, it could be a memory corruption.
Currently I have really no clue about how to spot the bug. Any idea? Carlo.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #27 from Ken Thomases ken@codeweavers.com 2013-09-15 14:11:20 CDT --- You could see if a +tid,+seh,warn+heap log finds anything. You could try running it under Valgrind.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #28 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-15 14:13:12 CDT --- I'm trying valgrind. I'll try also the other options. Thanks, Carlo.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #29 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-15 14:47:57 CDT --- Created attachment 45966 --> http://bugs.winehq.org/attachment.cgi?id=45966 log with: +tid,+seh,warn+heap
There are plenty of windows exceptions and above all various
0062:err:heap:HEAP_ValidateInUseArena Heap 0x110000: block 0x25eeef00 tail overwritten at 0x25eeef08 (byte 0/8 == 0x82)
which confirm it's a case of memory corruption.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #30 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-15 14:51:24 CDT --- Strangely I hadn't noticed these before, but shouldn't err messages be logged anyway?
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #31 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-15 15:14:22 CDT --- Strangely I hadn't noticed these before, but shouldn't err messages be logged anyway?
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #32 from Carlo Marchiori carlo.marchiori@gmail.com 2013-09-15 15:19:02 CDT --- Created attachment 45967 --> http://bugs.winehq.org/attachment.cgi?id=45967 Log with valgrind
With valgrind the game crashes very early. Also it rants about RtlAllocateHeap at heap.c:255, but there, actually, I find code generated by valgrind instrumentation
/* notify that a new block of memory has been allocated for debugging purposes */ static inline void notify_alloc( void *ptr, SIZE_T size, BOOL init ) { #ifdef VALGRIND_MALLOCLIKE_BLOCK /* line 255 */ VALGRIND_MALLOCLIKE_BLOCK( ptr, size, 0, init ); #endif }
Anyway I attach the log.
http://bugs.winehq.org/show_bug.cgi?id=34367
--- Comment #33 from Ken Thomases ken@codeweavers.com 2013-09-15 16:21:28 CDT --- All of the complaints about things being "lost" are about leaks. Those aren't good, but probably not the source of the freeze. The stack traces on those indicate where the leaked block was allocated, so of course RtlAllocateHeap() is often on the top of the stack. But in most of those cases, if not all, the rest of the trace goes into the game program itself, so it's indicating game bugs.
Of more interest are the invalid reads and the use of uninitialized values. Most of the ones that were reported seem to be inside the game code, too. Valgrind stopped reporting after hitting its limit, though.
You could try to disable or suppress certain checks to try to reduce the noise, but I'm not sure how fruitful it's going to be. There are so many problems that finding the one actually causing the freeze is going to be hard.
https://bugs.winehq.org/show_bug.cgi?id=34367
jre.winesim@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jre.winesim@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=34367
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Abandoned?
--- Comment #34 from Ken Sharp imwellcushtymelike@gmail.com --- Is this still an issue in Wine 1.7.44 or later?
https://bugs.winehq.org/show_bug.cgi?id=34367
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|ken@codeweavers.com |
https://bugs.winehq.org/show_bug.cgi?id=34367
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |ABANDONED Status|UNCONFIRMED |RESOLVED
--- Comment #35 from Ken Sharp imwellcushtymelike@gmail.com --- Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=34367
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #36 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org