https://bugs.winehq.org/show_bug.cgi?id=37892
--- Comment #4 from Marc Bessières marc.bessieres@gmail.com --- Thank you both for looking into this bug. Sorry for the delay in answering.
I checked again and here is what I find: 1.7.33 works 1.7.34 fails 1f7683777babab98197c39e5965ba6f70c01c8d0 works ca51e113e4820f8b11016c13732b1a971d2b0054 fails
1f7683777babab98197c39e5965ba6f70c01c8d0 is the commit just before ca51e113e4820f8b11016c13732b1a971d2b0054
Sorry for the complicated regression procedure, but after finding ca51e113e4820f8b11016c13732b1a971d2b0054 and trying to revert it on top of 1.7.34 Vdfs32e.exe didn't work. So I tried bisecting again and again, each reverting the previously found "bad" commit(s).
As I see that Bela doesn't manage to make it work ever, I would agree with Sebastian on the fact that it might be related to some corruption, luckily or unluckily it is just repeatedly working here with the same commit, and failing after the same one.
This gave me the idea to give valgrind a try: export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes --gen-suppressions=all --leak-check=full --num-callers=20 --workaround-gcc296-bugs=yes --vex-iropt-register-updates=allregs-at-mem-access"
I started winefile without valgrind to start the wineserver then I ran: valgring ./wine $WINEPREFIX//drive_c/Program\ Files/JoWooD\ Productions\ Software\ AG/Gothic\ II\ Gold/system/Vdfs32e.exe
And within the list of reports there is one that may be related, as part of it (loader.c:2870) corresponds to part of the stack trace of the crash (I couldn't find it in Austin English suppression files mentionned in the wiki) ==2388== Conditional jump or move depends on uninitialised value(s) ==2388== at 0x4016C2: ??? ==2388== by 0x4B91B9B: ??? (in /home/guest/wine-git/dlls/kernel32/kernel32.dll.so) ==2388== by 0x4B92C42: start_process (process.c:1104) ==2388== by 0x4871ADF: ??? (in /home/guest/wine-git/dlls/ntdll/ntdll.dll.so) ==2388== by 0x4874C0C: call_thread_func (signal_i386.c:2723) ==2388== by 0x4871ABD: ??? (in /home/guest/wine-git/dlls/ntdll/ntdll.dll.so) ==2388== by 0x484675D: start_process (loader.c:2870) ==2388== by 0x403FB9C: ??? (in /home/guest/wine-git/libs/wine/libwine.so.1.0) ==2388== Uninitialised value was created by a stack allocation ==2388== at 0x401216: ??? ==2388== { <insert_a_suppression_name_here> Memcheck:Cond obj:* obj:/home/guest/wine-git/dlls/kernel32/kernel32.dll.so fun:start_process obj:/home/guest/wine-git/dlls/ntdll/ntdll.dll.so fun:call_thread_func obj:/home/guest/wine-git/dlls/ntdll/ntdll.dll.so fun:start_process obj:/home/guest/wine-git/libs/wine/libwine.so.1.0 }
I just don't know why valgrind doesn't manage to decode some addresses, especially the stack allocation one... I may ask some valgrind people at FOSDEM.
While I was trying to launch Vdfs32e.exe several times to write that entry, Vdfs32e.exe worked once. So this is definitely not a regression.
Could someone with the right rights in Bugzilla remove the keyword and the sha1 entry? Also at the same time may be put it also in NEW as Bela confirmed the failure of Vdfs32e.exe