[Bug 59571] New: Heroes of Might and Magic 5 - Crash on launch
http://bugs.winehq.org/show_bug.cgi?id=59571 Bug ID: 59571 Summary: Heroes of Might and Magic 5 - Crash on launch Product: Wine Version: 11.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: accounts.winehq@vv221.fr Distribution: --- On current WINE, Heroes of Might and Magic 5 crashes right after showing its splash screen, before playing the introduction video and the following game menu. It seems to be a regression, as the same game version starts fine with WINE 7.0.2, but crashes with WINE 8.0.2. Interestingly, Debian-provided WINE 10.0 does not crash (this is why I did not notice this crash until now), so it might include something of value in its patches set. It is maybe worth nothing that a zlib1.dll shipped with the game must be used with upstream WINE, but the same library is not required with Debian WINE (does it come with its own copy of that library?). I am going to find the 8.x development update that introduced this crash, then run a regression test to identify the exact faulty commit. -- 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=59571 --- Comment #1 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- Last working version: 8.0-rc3 First broken version: 8.0-rc4 I am now on my way to run a bisect between these two versions, see if I can identify a specific commit introducing the crash. -- 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=59571 Antoine Le Gonidec <accounts.winehq@vv221.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- 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=59571 --- Comment #2 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- Created attachment 80628 --> http://bugs.winehq.org/attachment.cgi?id=80628 WINE 8.0-rc3 build failure WINE 8.0-rc3 fails to build on my system (Debian Sid amd64), preventing me from running a bisect. Any help in how to fix that build would be welcome. -- 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=59571 --- Comment #3 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- Created attachment 80629 --> http://bugs.winehq.org/attachment.cgi?id=80629 WINE 8.0-rc4 build failure WINE 8.0-rc4 does not build either, see the attached log. -- 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=59571 Alex Henrie <alexhenrie24@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexhenrie24@gmail.com --- Comment #4 from Alex Henrie <alexhenrie24@gmail.com> --- Try running `export CFLAGS=-std=gnu99 CROSSCFLAGS=-std=gnu99` before `./configure` and `make`. -- 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=59571 --- Comment #5 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- Sadly setting -std=gnu99 does not help, I still get the exact same error. I can get rid of it by running ./configure with --without-mingw, but then I get a wine binary that seemingly can not display any window, not even the one usually shown during the initialisation of the prefix. Keeping in mind that I can not be sure that the missing windows are due to that option. Here is my full build command: CC="ccache gcc -m32" ./configure --verbose --disable-tests --without-freetype --without-mingw && CC="ccache gcc -m32" make -j6 -- 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=59571 --- Comment #6 from Alex Henrie <alexhenrie24@gmail.com> --- (In reply to Antoine Le Gonidec from comment #5)
Sadly setting -std=gnu99 does not help, I still get the exact same error.
You mentioned two different errors: 8.0-rc3 failed to build because __fastfail was already defined, and 8.0-rc4 failed to build because "true" is a reserved keyword in the current C standard. I don't know how to resolve the __fastfail error, but with -std=gnu99 you should be able to build at commit 4d8091cccc4, which was halfway between 8.0-rc3 and 8.0-rc4, and at least narrow down the regression to a range of commits.
I can get rid of it by running ./configure with --without-mingw, but then I get a wine binary that seemingly can not display any window, not even the one usually shown during the initialisation of the prefix.
Yeah, I'd avoid using --without-mingw if at all possible.
Keeping in mind that I can not be sure that the missing windows are due to that option. Here is my full build command: CC="ccache gcc -m32" ./configure --verbose --disable-tests --without-freetype --without-mingw && CC="ccache gcc -m32" make -j6
I would expect --without-freetype to cause a lot of problems, and I don't think you should be using -m32 either. The easiest way to compile Wine is to make a "new WoW64" build with `./configure --enable-archs=i386,x86_64 && make -j6`. Before you run `./configure`, you can run `git clean -fdx` to remove any files from a previous build. If you still get a __fastfail error, try building without ccache. -- 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=59571 --- Comment #7 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- My bad, I noticed the failure with __fastfail was still there so I did not think about checking the other build. About --without-freetype, I added it because the ./configure call fails without it:
configure: error: FreeType 32-bit development files not found. Fonts will not be built. This is despite libfreetype-dev:i386 being installed, and /usr/lib/i386-linux-gnu/pkgconfig/freetype2.pc being available.
About the real 32-bit build, the new WoW64 mode is still not ready for my needs. But maybe for a bisect it is not all that important, and I can run a bisect using WoW64 despite the original bug being reported from a real 32-bit build? -- 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=59571 --- Comment #8 from Alex Henrie <alexhenrie24@gmail.com> --- (In reply to Antoine Le Gonidec from comment #7)
About --without-freetype, I added it because the ./configure call fails without it:
configure: error: FreeType 32-bit development files not found. Fonts will not be built. This is despite libfreetype-dev:i386 being installed, and /usr/lib/i386-linux-gnu/pkgconfig/freetype2.pc being available.
If you are doing an "old WoW64" build, you likely need to set the environment variable PKG_CONFIG_PATH=/usr/lib/i386-linux-gnu when doing the 32-bit configure and make.
About the real 32-bit build, the new WoW64 mode is still not ready for my needs. But maybe for a bisect it is not all that important, and I can run a bisect using WoW64 despite the original bug being reported from a real 32-bit build?
If you can reproduce the bug with either "new WoW64" or "old WoW64" then it doesn't matter. -- 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=59571 --- Comment #9 from Alex Henrie <alexhenrie24@gmail.com> --- Actually, you're probably going to run into another problem compiling Wine 8.0 on Debian Sid: Recent changes to binutils mean that any version of Wine compiled without commits fd59962827a and c9519f68ea0 will crash on start. You'll likely have to check out the commit that you want to test and then cherry-pick those two commits on top of it in order to get a functional build. -- 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=59571 Alex Henrie <alexhenrie24@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://dn710300.ca.archive | |.org/0/items/HeroesOfMightM | |agicV/Heroes%20of%20Might%2 | |0%26%20Magic%20V.exe --- Comment #10 from Alex Henrie <alexhenrie24@gmail.com> --- I was not able to install the Heroes of Might and Magic V demo with a "new WoW64" build of Wine 8.0, but I was able to install it with an "old WoW64" build of Wine 8.0. After commit 69a730090ab the demo crashes on a null pointer write. On an "old WoW64" build of Wine 11.5 the demo shows the error "Failed to initialize Direct3D 9" and exits. However, the demo runs without error on a "new WoW64" build of Wine 11.5. This looks like a duplicate of Bug 57461 and Bug 54833, and the solution is to use a recent "new WoW64" build. -- 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=59571 --- Comment #11 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- Sadly PKG_CONFIG_PATH=/usr/lib/i386-linux-gnu does not help. Keeping in mind that even without it, all other dependencies are correctly detected. The error only happens with FreeType. I am slowly realising that old vs. new WoW64 might not actually be what I was thinking about. What I need is some build with support for WINEARCH=win32, is the "new" mode going to provide me with that? Anyway, I’m going to try and reproduce the bug with a build using --enable-archs instead of -m32, as it seems to be the best way to unblock that situation. The two extra required commits are not going to be too big of a nuisance, since you gave me their identifiers I can easily apply them on top of each step of the bisect. --- I still get the __fastfail build failure even without ccache (now in the new WoW64 mode, without any need to disable FreeType support this time), I am going to try a new test setup excluding all commits before 4d8091cccc4 like you suggested earlier. --- I hit a wall again: WINE 8.0-rc4 (+ the 2 extra commits) fails to even start the game when built with:
CFLAGS=-std=gnu99 CROSSCFLAGS=-std=gnu99 CC="ccache gcc" ./configure --verbose --disable-tests --enable-archs=x86_64,i386 && make -j6
I need to investigate a bit more, but for now either I use the time namespace with unshare described in AppDB and WINE crashes, or I do not use that namespace and all I get is a black window instead of the splash screen. -- 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=59571 --- Comment #12 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- Unless the new WoW64 mode got all its performance problems fixed (mainly with OpenGL 32-bit games), this is sadly not going to be a satisfying solution. By the way, I did get crashes similar to what is described in https://bugs.winehq.org/show_bug.cgi?id=54833 (on maps loading) with a WINE build that does not trigger the crash described here (on game start). This is why I reported this as a new bug. I am going to try a WoW64 build of current WINE master anyway (or at least 11.6), see if it has a positive effect on that crash. -- 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=59571 --- Comment #13 from Alex Henrie <alexhenrie24@gmail.com> --- (In reply to Antoine Le Gonidec from comment #11)
I am slowly realising that old vs. new WoW64 might not actually be what I was thinking about. What I need is some build with support for WINEARCH=win32, is the "new" mode going to provide me with that?
No, WINEARCH=win32 is not supported in either old WoW64 or new WoW64. WINEARCH=win32 is used to create a 32-bit-only Wine bottle. But there is rarely a good reason to create a 32-bit-only bottle instead of using WoW64; why do you think you need one?
I hit a wall again: WINE 8.0-rc4 (+ the 2 extra commits) fails to even start the game when built with:
CFLAGS=-std=gnu99 CROSSCFLAGS=-std=gnu99 CC="ccache gcc" ./configure --verbose --disable-tests --enable-archs=x86_64,i386 && make -j6
Yes, I ran into that problem too. It seems that back in Wine 8.0 (which is three years old now), new WoW64 was not good enough to run Heroes of Might and Magic 5 at all. That means that you can't use new WoW64 to bisect the regression, sorry to mislead you. (In reply to Antoine Le Gonidec from comment #12)
Unless the new WoW64 mode got all its performance problems fixed (mainly with OpenGL 32-bit games), this is sadly not going to be a satisfying solution.
As of Wine 11.0, 32-bit OpenGL should perform about as well in new WoW64 as in old WoW64, thanks to a clever trick that uses Vulkan to allocate OpenGL memory in the first 4 GiB of the address space. If you haven't tried new WoW64 in a while, it's worth trying again now.
By the way, I did get crashes similar to what is described in https://bugs.winehq.org/show_bug.cgi?id=54833 (on maps loading) with a WINE build that does not trigger the crash described here (on game start). This is why I reported this as a new bug.
I think they're fundamentally the same bug: The game is memory-hungry and on 32-bit-only Wine or on old WoW64, after loading all of the required Unix libraries, there isn't enough memory left in the address space for the game. Whether the game runs out of memory immediately or upon starting gameplay doesn't change the diagnosis. -- 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=59571 --- Comment #14 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- About WINEARCH=win32, it is mostly due to lack of time to test WoW64, both old and new. When I finally started hearing about it again, it was because distributions switching to the new WoW64 mode made many games unplayable, so of course it did not lead me to be an early adopter ;) Then there is the problem of twice the storage space being required to generate the WINE prefix, while half of that is never going to be used if only 32-bit software is going to be run (based on my experience with the old mode, I don’t know if it is still the case with the new one). Another problem with my use case is that many winetricks calls take twice as long to run, sometimes with twice as much user interaction, because 64-bit builds of libraries are being installed despite having no use in that specific prefix. As I said above, I am going to give a try to a current build with WoW64 (new variant) anyway. No matter if I am going to use it or not, it is worth knowing if it has a positive effect on this crash. --- I find it strange that this problem would be memory related, especially as the crashes I got on maps loading (#54833 ?) only happened with the base game alone, not with the expansions. And I expect the expansions to eat a bit more memory, due to having more content. My workaround for this crash on maps loading, workaround that has no effect on the current crash, is to restore a previous version of the game binary. I did not get that crash with any GOG.com builds before the most current one, where they did change something to the game binary without documenting 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=59571 --- Comment #15 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- Scratch what I wrote earlier, it is indeed a memory-related problem, and is most probably a variant of #54833. -- 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=59571 --- Comment #16 from Antoine Le Gonidec <accounts.winehq@vv221.fr> --- I can confirm that this crash does not happen with the new WoW64 mode, WINE 11.6. But on the same WINE 11.6, the crash still happens systematically with a 32-bit prefix. -- 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=59571 --- Comment #17 from Alex Henrie <alexhenrie24@gmail.com> --- (In reply to Antoine Le Gonidec from comment #14)
Then there is the problem of twice the storage space being required to generate the WINE prefix, while half of that is never going to be used if only 32-bit software is going to be run (based on my experience with the old mode, I don’t know if it is still the case with the new one).
Another problem with my use case is that many winetricks calls take twice as long to run, sometimes with twice as much user interaction, because 64-bit builds of libraries are being installed despite having no use in that specific prefix.
In 32-bit-only Wine or in old WoW64, this bug is likely unfixable because, unlike Windows, Wine has to have both Windows libraries and Unix libraries in memory at the same time. New WoW64 elegantly solves the memory problem by using 64-bit Unix libraries and placing them above the 4 GiB mark. My guess is that a 32-bit-only Wine that uses 64-bit Unix libraries so as to not clutter the 32-bit address space is theoretically possible, but there is so little demand for it that it will never be a supported configuration. Your best option might be to switch to a copy-on-write filesystem like btrfs so that at least you aren't physically duplicating files between /usr/lib/wine and ~/.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=59571 --- Comment #18 from Antoine Le Gonidec <accounts.winehq@vv221.fr> ---
In 32-bit-only Wine or in old WoW64, this bug is likely unfixable (…)
Well, Debian-provided WINE 10.0 is proof that it is fixable ;) I noticed that crash so late, like I wrote in the original report, because it does not happen with Debian-provided packages. This is the main reason why I am so insistent on looking for the actual regression, or any hint on the root cause of the crash. -- 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)
-
WineHQ Bugzilla