http://bugs.winehq.org/show_bug.cgi?id=30787
Bug #: 30787 Summary: Heroes of Might and Magic V Map Editor takes minutes to start up (winver>=Win2000) Product: Wine Version: 1.5.5 Platform: x86 OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: gyebro69@gmail.com Classification: Unclassified
Created attachment 40316 --> http://bugs.winehq.org/attachment.cgi?id=40316 winedbg backtrace during the busy state
It takes 3-4 minutes until the Map Editor for HoMM V appears when Windows version is set to Win2000 or higher in winecfg. Using Win9x/Me, or WinNT40/35 profiles, the editor loads up in less than 10 seconds.
Wine doesn't print anything in the terminal until the editor window appears. There is no hdd activity, but cpu usage is constantly ~100 % while Wine is busy with loading the editor.
If I attach winedbg to the H5_MapEditor.exe process, I always get the same backtrace as can be seen in the attachment.
It should be noted that bug #29603 describes a very similar problem. Of course I have no proof if they're about the same problem, but the similarities are striking.
Fedora 16 x86 gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) Kernel 3.3.7-1.fc16.i686.PAE
http://bugs.winehq.org/show_bug.cgi?id=30787
--- Comment #1 from GyB gyebro69@gmail.com 2012-05-28 14:26:52 CDT --- With WINEDEBUG=warn+heap there is only one warning just as the application starts: warn:heap:validate_block_pointer Heap 0x110000: pointer 0x34eb80 is not inside heap
then two more added as the editor window finally appears: warn:heap:validate_block_pointer Heap 0x110000: pointer 0x33cf40 is not inside heap warn:heap:validate_block_pointer Heap 0x110000: pointer 0x33dc50 is not inside heap
Memory consumption isn't changing considerably during the long 'busy' period. It reaches the top right after the application was started: VIRT: 1585M RES: 123M SHR: 18988
When the editor window appears: VIRT: 1694M RES: 232M SHR: 66644
What could be the difference between Win98 and WinXP modes in Wine which makes such a long loading time?
http://bugs.winehq.org/show_bug.cgi?id=30787
Xavier Vachon xvachon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xvachon@gmail.com
--- Comment #2 from Xavier Vachon xvachon@gmail.com 2012-10-09 18:29:46 CDT --- Still a bug in 1.5.14
https://bugs.winehq.org/show_bug.cgi?id=30787
--- Comment #3 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.28 or newer) wine? If so, please attach the terminal output in 1.7.28 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=30787
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #4 from Wylda wylda@volny.cz --- Still present in wine-1.7.28, but starting times are similar: * Win98: 1min 35sec * WinXP: 1min 21sec
https://bugs.winehq.org/show_bug.cgi?id=30787
--- Comment #5 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Wylda from comment #4)
Still present in wine-1.7.28, but starting times are similar:
- Win98: 1min 35sec
- WinXP: 1min 21sec
Yes, in recent Wine versions loading times are roughly the same whether I'm using the default WinXP profile or Win98 profile (more than 3 minutes on my system). It's probably because nowadays Wine uses the built-in msvc* dlls unless you override them in winecfg. The game comes bundled with it's own msvcp71 and msvcr71 dlls, if I override msvcr71 to native,builtin, then the map editor loads in less than 5 seconds in Win98 mode. Native msvcr71 has no effect on loading times when using the default XP profile, interestingly.
wine-1.7.49-104-gbd7f43d Fedora 22 32-bit Tested with the GOG.com version
https://bugs.winehq.org/show_bug.cgi?id=30787
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #6 from Béla Gyebrószki gyebro69@gmail.com --- The problem doesn't occur in recent Wine (tested in 3.13). This ticket can be closed as fixed.
https://bugs.winehq.org/show_bug.cgi?id=30787
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.14.