[Bug 11188] New: Most attempts to save in Warcraft III 1. 21a Reign of Chaos crash the game
http://bugs.winehq.org/show_bug.cgi?id=11188
Summary: Most attempts to save in Warcraft III 1.21a Reign of Chaos crash the game Product: Wine Version: 0.9.52. Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: louis@qdcec.co.za
I am running Warcraft III Reign of Chaos patched to 1.21a on Fedora 7 x86_64 on an AMD Athlon 64 with a Radeon X1300. The game runs smoothly but MOST times when I try to save, the save dialog comes up, I enter a save name, I select overwrite if applicable, the words Saving Game appear. Now if all goes well the words turn green and the game continues. If it fails, the words remain there in white, the sound continues playing, but nothing else happens. If I overwrote a saved game, that game is no longer in my list of saved games. The only way out is to wineboot -k -f -s and then to restart from the last successful saved game. I notice that usually (not always) I can save a game in the very beginning of the game, and as long as I save again soon it may work. However, 4 out of 5 times it crashes, making the game very unplayable (if I need to save -- which I do).
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #1 from Austin English austinenglish@gmail.com 2008-01-14 14:59:41 --- Does this demo have the same problem?
http://www.mofunzone.com/download_games/warcraft_iii_reign_of_chaos.shtml
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #2 from Louis louis@qdcec.co.za 2008-01-16 15:49:07 --- (In reply to comment #1)
Does this demo have the same problem?
http://www.mofunzone.com/download_games/warcraft_iii_reign_of_chaos.shtml
I am not certain about the demo. I will download it in the morning and report back here.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #3 from Louis louis@qdcec.co.za 2008-01-19 17:46:58 --- I have upgraded to Wine 0.9.53. The game still crashes on saving.
As requested I downloaded the Demo and ran that. I got it to crash in the same way -- TWICE. However, in THIS version a pop-up box appeared. I have quoted the error. Note the lines that say FIRST TIME and SECOND TIME refer to each of the crashes I have experienced in the Demo version test. Take note the same error at the same address occurs.
War3Demo This application has encountered a critical error: FATAL ERROR! Program: C:\Program Files\Warcraft III Demo\War3Demo.exe Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:7EF93E7B The instruction at '0x7EF93E7B' referenced memory at '0x0B8700B8'. - FIRST TIME The instruction at '0x7EF93E7B' referenced memory at '0x0AEA00B8'. - SECOND TIME The memory could not be 'written'. Press OK to terminate the application.
http://bugs.winehq.org/show_bug.cgi?id=11188
Michiel de Bruijne m.debruijne@matrict.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |m.debruijne@matrict.nl
http://bugs.winehq.org/show_bug.cgi?id=11188
Rico kgbricola@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kgbricola@web.de
--- Comment #4 from Rico kgbricola@web.de 2008-02-10 10:59:25 --- I've tried the demo and played the prologue. I saved about 30 times and the game run without any problems.
wine 0.9.55. GPU 8800GTS Fedora 7 x86_64
Could you try with a fresh .wine directory?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #5 from John Stahara staharaj@gmail.com 2008-02-13 22:25:29 --- Created an attachment (id=10760) --> (http://bugs.winehq.org/attachment.cgi?id=10760) warn+all with clean ~/.wine directory
I also have this problem (with the Frozen Throne expansion, as well), and have attached the part of the output following the Save attempt, with WINEDEBUG=warn+all. This is with a new .wine directory and only importing the [HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III] registry branch from the previous.
Let me know if there's anything else I can do to help.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #6 from John Stahara staharaj@gmail.com 2008-02-14 01:36:24 --- Created an attachment (id=10764) --> (http://bugs.winehq.org/attachment.cgi?id=10764) War3 crash report
Game-generated crash report from my Errors directory.
http://bugs.winehq.org/show_bug.cgi?id=11188
John M. Drescher drescherjm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |drescherjm@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #7 from John M. Drescher drescherjm@gmail.com 2008-02-17 21:54:36 --- I am getting this as well. I am using wine-0.9.55 and Warcraft III 1.21a TFT. For me it usually happens on the first save and if I get a successful save all is usually well after that.
Here is what I had in the console after the last Acess Violation:
err:ole:CoCreateInstance apartment not initialised fixme:advapi:SetSecurityInfo stub fixme:win:EnumDisplayDevicesW ((null),0,0x33f3d8,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33f64c,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33f67c,0x00000000), stub! fixme:ntdll:find_reg_tz_info Can't find matching timezone information in the registry for bias 300, std (d/m/y): 2/11/2008, dlt (d/m/y): 9/03/2008 fixme:imm:ImmGetOpenStatus (0x135298): semi-stub fixme:imm:ImmReleaseContext (0x30024, 0x135298): stub fixme:imm:ImmGetOpenStatus (0x135298): semi-stub fixme:dbghelp:EnumerateLoadedModulesW64 If this happens, bump the number in mod fixme:dbghelp:EnumerateLoadedModulesW64 If this happens, bump the number in mod fixme:dbghelp:dump_system_info fill in CPU vendorID and feature set
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #8 from Rico kgbricola@web.de 2008-02-18 11:59:11 --- @ John M. Drescher What are your system specs (Distribution, CPU, GPU, ...?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #9 from John M. Drescher drescherjm@gmail.com 2008-02-18 13:24:45 --- Distro: Gentoo 2007.0 x86_64 (updated to current) CPU: Opteron 285 GPU: nVidia GeForce4 Ti 4200 AGP 8x Memory: 4GB of REG PC3200 ECC
I also did not mention that this did not happen with wine-0.9.54 + a 2.6.22 kernel + previous patch of Warcraft. I updated all three (wc2 to latest patch via battlenet + kernel to 2.6.24 openvz + wine to 0.9.55) in the last 2 weeks then the save problem started. I had been playing the game for a few hours a week before these upgrades so I have tested this pretty well.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #10 from John M. Drescher drescherjm@gmail.com 2008-02-19 08:24:22 --- Also when the save works I see the following:
err:ole:CoCreateInstance apartment not initialised fixme:advapi:SetSecurityInfo stub fixme:win:EnumDisplayDevicesW ((null),0,0x34f3d8,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x34f64c,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x34f67c,0x00000000), stub! fixme:ntdll:find_reg_tz_info Can't find matching timezone information in the registry for bias 300, std (d/m/y): 2/11/2008, dlt (d/m/y): 9/03 /2008 fixme:imm:ImmGetOpenStatus (0x134318): semi-stub fixme:imm:ImmReleaseContext (0x30024, 0x134318): stub fixme:imm:ImmGetOpenStatus (0x134318): semi-stub fixme:imm:ImmAssociateContextEx (0x30024, (nil), 16): stub
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #11 from John M. Drescher drescherjm@gmail.com 2008-02-22 20:54:02 --- Created an attachment (id=10909) --> (http://bugs.winehq.org/attachment.cgi?id=10909) winedbg log
Attached winedbg output.
http://bugs.winehq.org/show_bug.cgi?id=11188
John M. Drescher drescherjm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #10909|application/octet-stream |application/text mime type| |
http://bugs.winehq.org/show_bug.cgi?id=11188
John M. Drescher drescherjm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #10909|application/text |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=11188
soxs schuster.bernhard@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |schuster.bernhard@googlemail | |.com
--- Comment #12 from soxs schuster.bernhard@googlemail.com 2008-03-01 11:15:49 --- I have the very same problem. Running Ubuntu hard 8.04, AMD X2 3800+, nvidia 7600gt and runs pretty fine. For me saving is like playing roulette...
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #13 from John M. Drescher drescherjm@gmail.com 2008-03-01 15:51:03 --- It's beginning to feel like that to me as well. This is really painful because I was playing the game for each evening but now I am very scared to hit the save button because it could mean I will have to replay the level from the last successful save. This has brought my progress through the campaigns to a halt...
Anyways I did some debugging and increasing the resolution from 800x600 to 1280x1024 has seemed to reduce the chance of this but I could be wrong. Also when the crash occurs it always has begun writing the file and most times it gets more than 1/2 of the file written. On my system the save files are generally between 2MB and 4MB and it generally fails at the 1.7MB mark but once it failed after writing 700K.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #14 from John M. Drescher drescherjm@gmail.com 2008-03-03 21:45:29 --- For the last few evenings I have been testing previous versions of wine and to this point I have reproduced this behavior with wine-0.9.51 and WC3 TFT 1.21b which is what I am now using.
http://bugs.winehq.org/show_bug.cgi?id=11188
Giacomo Graziosi g.graziosi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |g.graziosi@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #15 from Ian idan@eircom.net 2008-04-07 14:33:29 --- Created an attachment (id=11933) --> (http://bugs.winehq.org/attachment.cgi?id=11933) Dialog box and terminal output when save crashes
http://bugs.winehq.org/show_bug.cgi?id=11188
Ian idan@eircom.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |idan@eircom.net
--- Comment #16 from Ian idan@eircom.net 2008-04-07 14:34:18 --- I'm having the same issue, some times saves work but others they crash. I'm using Ubuntu 8.04, intel i850 and a pentium M 1.6. I've attached the text of the dialog box and the terminal output when a save crashes the game, as well as for when the save is successfull.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #17 from Ian idan@eircom.net 2008-04-07 14:35:09 --- Created an attachment (id=11934) --> (http://bugs.winehq.org/attachment.cgi?id=11934) Terminal output when save is successful
http://bugs.winehq.org/show_bug.cgi?id=11188
Peter Ebden peter@ebden.co.nz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |peter@ebden.co.nz
--- Comment #18 from Peter Ebden peter@ebden.co.nz 2008-05-04 02:59:43 --- I have the same issue - random memory access crashes. Crashes appear to occur at arbitrary times - not random in the sense that they're repeatable, but it's not obvious when it'll occur. Sometimes occurs on saving, sometimes at mission completion.
Have tried downgrading Wine to several earlier versions (back into the .30's) which hasn't fixed it completely, although tends to change exactly when it occurs. Am pretty sure that versions back then were working fairly flawlessly in the past, which suggests to me that this has been triggered by something else updating (X? Kernel?).
Am running x86_64 Gentoo on an Athlon64, with a 7800GT, if any of that is important. If there's any other information I can supply that's useful, please let me know.
http://bugs.winehq.org/show_bug.cgi?id=11188
michal.modzel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michal.modzel@gmail.com
--- Comment #19 from michal.modzel@gmail.com 2008-05-20 18:35:08 --- Hello, I have just installed W3:TRoC, patched it to 1.21b, make it run with opengl. Game always (I know that others managed to save at least once, but I wasn't that lucky) crashes when I'm trying to save and after few seconds it displays error dialog box similar to that posted by Ian (although the numbers are differrent), but I can still hear music playing. I've tried warcraft demo but problem persists. I'm running: AMD Athlon 64 X2 Dual Core 4000+ Ati Radeon HD2600 Pro 2GB Ram Wine 0.9.59 Kubuntu 8.04. Kernel: 2.6.24-16-generic
http://bugs.winehq.org/show_bug.cgi?id=11188
Thomas Benn sotis@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sotis@gmx.net
--- Comment #20 from Thomas Benn sotis@gmx.net 2008-05-28 02:38:01 --- Same here. Using wine 0.9.57 on a gentoo machine with a 2.6.24-gentoo-r8 kernel, nvidia 7600GT as video card. Crashed on my 2nd saving attempt with a fresh wine install, fresh Warcraft install.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #21 from Thomas Benn sotis@gmx.net 2008-05-28 02:40:25 --- Dang, forget to say: I am running on a AMD64 machine as well, though I also encountered that problem on my laptop, Intel processor (3 years old, no dual core) and ATI video card using arch linux..
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #22 from Rico kgbricola@web.de 2008-05-28 10:52:22 --- I have kernel 2.6.23 and the game runs without any problems. Could someone try an older kernel? It looks like the crash happens with kernelversion 2.6.24, is that correct?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #23 from John M. Drescher drescherjm@gmail.com 2008-05-28 11:00:59 --- I can do that when I get home (6 to 8 hours from now). I am pretty sure there is still a 64 bit vserver 2.6.22 kernel in grub since I tend to leave the old kernels alone.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #24 from John M. Drescher drescherjm@gmail.com 2008-05-28 23:31:56 --- I think that was it. I played one campaign for 10 minutes saving 2 times and hit this bug under a 2.6.24 kernel using wine-0.9.61. Under the same system with a 2.6.22 kernel I played over 1 hour saving at least 20 times and I did not see the bug.
A few interesting tidbits. When I ran in the 2.6.24 kernel I got the following mesages just after opening a cmd session that I launched war3 from:
WINEPREFIX="/home/john/.wine.cur" wine fixme:ntdll:find_reg_tz_info Can't find matching timezone information in the registry for bias 300, std (d/m/y): 2/11/2008, dlt (d/m/y): 9/03/2008 fixme:system:SetProcessDPIAware stub! fixme:iphlpapi:NotifyAddrChange (Handle 0x7dc689f8, overlapped 0x7dc689dc): stub fixme:shell:DllCanUnloadNow stub wine: configuration in '/home/john/.wine.cur' has been updated.
However in 2.6.22 I did not see any of that: $ WINEPREFIX="/home/john/.wine.cur" wine cmd CMD Version 0.9.61
D:>c: C:>cd cd Program Files/Warcraft III Path not found
C:>cd Program Files/Warcraft III C:\Program Files\Warcraft III>war3 -opengl C:\Program Files\Warcraft III>err:ole:CoCreateInstance apartment not initialised fixme:advapi:SetSecurityInfo stub fixme:win:EnumDisplayDevicesW ((null),0,0x33f3a0,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33f64c,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33f67c,0x00000000), stub! fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmReleaseContext (0x40022, 0x136008): stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmGetOpenStatus (0x136008): semi-stub fixme:imm:ImmAssociateContextEx (0x40022, (nil), 16): stub
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #25 from John M. Drescher drescherjm@gmail.com 2008-05-29 00:08:43 --- Created an attachment (id=13452) --> (http://bugs.winehq.org/attachment.cgi?id=13452) Second run with 2.6.24 in same campaign
I rebooted back to 2.6.24 and then entered the commands including the bad command in cmd just as I did in 2.6.22 and it this time tool > 20 minutes to get the bug and many, many saves. Attached is the log of this. Sorry about the inline message on the last go.. The log is very similar to the one for 2.6.22 except it has the error at the end. As a result I am not sure it could have been that if I played longer in 2.6.22 it would have done the same.
http://bugs.winehq.org/show_bug.cgi?id=11188
Matt Smith mattheo@bigpond.net.au changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mattheo@bigpond.net.au
--- Comment #26 from Matt Smith mattheo@bigpond.net.au 2008-05-31 08:58:30 --- My kernel is 2.6.25.3-18.fc9.i686 and I get the same error almost always when saving: fixme:dbghelp:dump_system_info fill in CPU vendorID and feature set
I have tried War3TFT 1.20d, 1.21b and 1.22 BETA on WINE 0.9.58 and AMD XP 2600.
http://bugs.winehq.org/show_bug.cgi?id=11188
Zhangrong Huang hzhrong@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hzhrong@gmail.com
--- Comment #27 from Zhangrong Huang hzhrong@gmail.com 2008-06-01 00:05:05 --- I think It's an issue of wine I/O completion port support, when you disable I/O completion port, it's OK. see this patch: http://bugs.winehq.org/attachment.cgi?id=8368
It's mostly happen in multi-thread applications.
http://bugs.winehq.org/show_bug.cgi?id=11188
Zhangrong Huang hzhrong@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #28 from Zhangrong Huang hzhrong@gmail.com 2008-06-01 00:10:57 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #29 from Thomas Benn sotis@gmx.net 2008-06-01 14:51:15 --- Interestingly enough I have been playing for more than an hour today, saving often and NEVER had any issues.. I do not believe I had any updates incoming, all I remember changing was to add the -opengl flag, which anyway solves a graphical glitch when I get back to my desktop..
Do you guys use -opengl or not?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #30 from soxs schuster.bernhard@googlemail.com 2008-06-01 14:53:05 --- I do, and I get 100% crashes when trying to save.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #31 from John M. Drescher drescherjm@gmail.com 2008-06-01 19:43:56 --- I have had this with and without the -opengl switch. If you have a GeForce 4 card or lower you can run wc3 with or without this switch.
http://bugs.winehq.org/show_bug.cgi?id=11188
Alexander Brüning lama@lamamail.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lama@lamamail.de
http://bugs.winehq.org/show_bug.cgi?id=11188
luke16 luke16@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luke16@gmail.com
--- Comment #32 from luke16 luke16@gmail.com 2008-07-17 22:59:00 --- I am experiencing this bug as well. It seems to be completely random, and my experiences with it seem to match most other people who've posted here. It happens in frozen throne as well, so it's not just confined to RoC. Athlon X2, 64bit ubuntu, nvidia 7950gt.
http://bugs.winehq.org/show_bug.cgi?id=11188
Claudio sick_soul@yahoo.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sick_soul@yahoo.it
--- Comment #33 from Claudio sick_soul@yahoo.it 2008-07-19 16:40:38 ---
Just want to add that I am also experiencing this bug. Slackware 12.1 on x86 (Pentium-4), linux kernel 2.6.26, wine-1.1.1, wc3 + Frozen Throne, patch level 1.22.0.6328
Once every third save I get the crash and the message
"This application has encountered a critical error:
FATAL ERROR!" etc etc.
http://bugs.winehq.org/show_bug.cgi?id=11188
Sebastian Doering moralapostel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |moralapostel@gmail.com
--- Comment #34 from Sebastian Doering moralapostel@gmail.com 2008-07-20 11:19:05 --- (In reply to comment #33)
Just want to add that I am also experiencing this bug. Slackware 12.1 on x86 (Pentium-4), linux kernel 2.6.26, wine-1.1.1, wc3 + Frozen Throne, patch level 1.22.0.6328
Once every third save I get the crash and the message
"This application has encountered a critical error:
FATAL ERROR!" etc etc.
I get the same error with wine-1.1.0 on Gentoo. Warcraft version: 1.21b
There seems to be no way to reduce the chance of the error happening.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #35 from Matt Smith mattheo@bigpond.net.au 2008-08-02 03:07:32 --- I was using a newer kernel (2.6.25) and this bug occurred frequently. I am now using 2.6.22 and I can now save and load without error.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #36 from Zhangrong Huang hzhrong@gmail.com 2008-08-03 01:07:48 --- (In reply to comment #35)
I was using a newer kernel (2.6.25) and this bug occurred frequently. I am now using 2.6.22 and I can now save and load without error.
I'm using Mac OS X 10.5.2, still got crash.
http://bugs.winehq.org/show_bug.cgi?id=11188
Michal Illich list@illich.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |list@illich.cz
--- Comment #37 from Michal Illich list@illich.cz 2008-08-06 16:22:50 --- I confirm this bug. - kernel-2.6.25.11-60.fc8 - wine-1.0-1.fc8 - Warcraft III Frozen Throne 1.18 - Fedora 8 (up-to-date)
Saves crash 80% of time. It was OK one month ago (don't know what caused it - if kernel update or wine update; Warcraft was the same version all the time)
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #38 from John M. Drescher drescherjm@gmail.com 2008-08-07 21:27:05 --- (In reply to comment #27)
I think It's an issue of wine I/O completion port support, when you disable I/O completion port, it's OK. see this patch: http://bugs.winehq.org/attachment.cgi?id=8368
It's mostly happen in multi-thread applications.
This patch looks like it has solved this issue for me. Two consecutive nights of playing wc3 with no save crashes at all. Also it appears saving is actually faster.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #39 from John M. Drescher drescherjm@gmail.com 2008-08-07 21:28:41 --- BTW, I am using a 2.6.24 kernel and wine 1.1.2 and wc3 1.22
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #40 from michal.modzel@gmail.com 2008-08-09 06:07:46 --- (In reply to comment #38)
(In reply to comment #27)
I think It's an issue of wine I/O completion port support, when you disable I/O completion port, it's OK. see this patch: http://bugs.winehq.org/attachment.cgi?id=8368
It's mostly happen in multi-thread applications.
This patch looks like it has solved this issue for me. Two consecutive nights of playing wc3 with no save crashes at all. Also it appears saving is actually faster.
And exactly how to apply this patch?:)
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #41 from John M. Drescher drescherjm@gmail.com 2008-08-09 15:53:15 ---
And exactly how to apply this patch?:)
I am using gentoo. I saved the file as wine-1.1.2-noiocp.patch and modifyied the ebuild call epatch on that file.
For any other distribution you will need the wine source and call patch -p0 < patchfile
You may need to consult the man pages for patch.
http://bugs.winehq.org/show_bug.cgi?id=11188
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #42 from Austin English austinenglish@gmail.com 2008-08-09 16:57:52 --- (In reply to comment #40)
(In reply to comment #38)
(In reply to comment #27)
I think It's an issue of wine I/O completion port support, when you disable I/O completion port, it's OK. see this patch: http://bugs.winehq.org/attachment.cgi?id=8368
It's mostly happen in multi-thread applications.
This patch looks like it has solved this issue for me. Two consecutive nights of playing wc3 with no save crashes at all. Also it appears saving is actually faster.
And exactly how to apply this patch?:)
http://wiki.winehq.org/Patching
http://bugs.winehq.org/show_bug.cgi?id=11188
Jan Jergus janjergus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |janjergus@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11188
Martin Jürgens martin@gamesplace.info changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |martin@gamesplace.info
http://bugs.winehq.org/show_bug.cgi?id=11188
nop nopnopzero@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nopnopzero@gmail.com
--- Comment #43 from nop nopnopzero@gmail.com 2008-10-26 10:00:13 --- I also confirm this bug. - 2.6.24-21-generic - wine-1.1.7 - Warcraft III Frozen Throne 1.22 - Ubuntu Hardy Heron (up-to-date)
crash every time I try to save.
It now works like a charm thanks to the patch http://bugs.winehq.org/attachment.cgi?id=8368
http://bugs.winehq.org/show_bug.cgi?id=11188
Yutong Zhao rakuen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rakuen@gmail.com
--- Comment #44 from Yutong Zhao rakuen@gmail.com 2008-10-28 18:13:30 --- (In reply to comment #27)
I think It's an issue of wine I/O completion port support, when you disable I/O completion port, it's OK. see this patch: http://bugs.winehq.org/attachment.cgi?id=8368
It's mostly happen in multi-thread applications.
This did the trick for me. Patched in Gentoo.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #45 from Yutong Zhao rakuen@gmail.com 2008-10-30 10:30:16 --- This is weird, after applying the wine patch listed above (http://bugs.winehq.org/attachment.cgi?id=8368),
it seems that only certain saved games can be loaded. The ones that can be loaded, will always load fine, while the those that can't be loaded results in a "Memory could not be "written"" error, every time.
Is this a consequence of the patch?
I'm starting to think that the game is crashing for a reason (ie. we're not supposed to be able to save the games that crash, as they are unable to be loaded.)
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #46 from John M. Drescher drescherjm@gmail.com 2008-10-30 11:04:10 --- I have not seen this effect. Are you sure that you are not loading games that were crashed?
I believe the bug is that the current wine io completion port implementation in wine does not work reliably 100% of the time. And the patch effectively disables IOCP.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #47 from Yutong Zhao rakuen@gmail.com 2008-10-30 11:42:51 --- (In reply to comment #46)
I have not seen this effect. Are you sure that you are not loading games that were crashed?
I believe the bug is that the current wine io completion port implementation in wine does not work reliably 100% of the time. And the patch effectively disables IOCP.
The crashed games didn't even save in the first place, so there was no way for me to have loaded them. I'm 100% sure that the games were saved after I patched it.
Although I'm 99% sure that I patched wine correctly, is there a way to diagnose if wine is using the IOCP or not? Also, which version of wine did you guys patch? I patched 1.1.6
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #48 from John M. Drescher drescherjm@gmail.com 2008-10-30 11:48:38 --- The last version I patched was 1.1.4. With the patched ebuild in my git gentoo overlay
http://github.com/drescherjm/jmdgentoooverlay/tree/master/app-emulation/wine
The reason why it was 1.1.4 was a video card problem has rendered me unable to play games on that machine at the moment.
http://bugs.winehq.org/show_bug.cgi?id=11188
Sergey Sergey.239@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Sergey.239@gmail.com
--- Comment #49 from Sergey Sergey.239@gmail.com 2008-11-08 09:31:38 --- I was able to save games in 1.1.18. in 1.1.17 when i tried to save game crashes. I use arch linux.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #50 from Sergey Sergey.239@gmail.com 2008-11-08 09:45:20 --- (In reply to comment #49)
I was able to save games in 1.1.18. in 1.1.17 when i tried to save game crashes. I use arch linux.
s/1.1.18/1.1.8
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #51 from luke16 luke16@gmail.com 2008-11-08 12:57:30 --- (In reply to comment #49)
I was able to save games in 1.1.18. in 1.1.17 when i tried to save game crashes. I use arch linux.
I still encounter crashes when I try to save in 1.1.18. /ubuntu hardy
http://bugs.winehq.org/show_bug.cgi?id=11188
Michael Monreal infernux@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |infernux@web.de
--- Comment #52 from Michael Monreal infernux@web.de 2008-11-09 03:08:43 --- (In reply to comment #51)
I still encounter crashes when I try to save in 1.1.18. /ubuntu hardy
Mee too.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #53 from nop nopnopzero@gmail.com 2008-11-09 04:52:07 --- (In reply to comment #52)
(In reply to comment #51)
I still encounter crashes when I try to save in 1.1.18. /ubuntu hardy
Mee too.
Have you applied the patch http://bugs.winehq.org/attachment.cgi?id=8368 on the 1.1.8 ?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #54 from Michael Monreal infernux@web.de 2008-11-09 11:34:59 --- (In reply to comment #53)
Have you applied the patch http://bugs.winehq.org/attachment.cgi?id=8368 on the 1.1.8 ?
No. Sadly I'm unable to build wine myself on this system ATM.
http://bugs.winehq.org/show_bug.cgi?id=11188
Reece Dunn msclrhd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |msclrhd@gmail.com
--- Comment #55 from Reece Dunn msclrhd@gmail.com 2008-11-25 03:27:48 --- Confirming that this is still an issue with wine 1.1.9. I haven't tried the patch yet, but will do later.
It does not make a difference if the game has a space in it or not: sometimes it works, sometimes it does not.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #56 from Zakhar eze@free.fr 2008-11-26 17:00:19 --- I compiled Wine 1.1.9 with this patch on Ubuntu 8.10 - 64Bits
I confirm it fixes the bug. ---------------------------
1.1.9 has bad sound with alsa for me (1.0.1 is OK) but luckily, with OSS sound it's fine. So now I'm enjoying Frozen Throne with no crash and perfect FPS and sound. Even full screen with compiz cube activated ! Better experience than the same game under Windows !
Anyway I don't think the fix should go to release. I have the impression it's rather a workaround as what is does is comment out a function in sync.c so that after patch the only thing the function does is return a code that all is OK, no matter if it is or not !
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #57 from Claudio sick_soul@yahoo.it 2008-11-27 00:23:00 --- (In reply to comment #56)
I compiled Wine 1.1.9 with this patch on Ubuntu 8.10 - 64Bits
I confirm it fixes the bug.
1.1.9 has bad sound with alsa for me (1.0.1 is OK) but luckily, with OSS sound it's fine. So now I'm enjoying Frozen Throne with no crash and perfect FPS and sound. Even full screen with compiz cube activated ! Better experience than the same game under Windows !
Anyway I don't think the fix should go to release. I have the impression it's rather a workaround as what is does is comment out a function in sync.c so that after patch the only thing the function does is return a code that all is OK, no matter if it is or not !
My opinion is that the problem is that the new feature they implemented (IO/completion) was put in to probably support some other application deemed more important, without any application regression testing.
So the new feature is actually implemented in a way to break existing functionality, but this is considered worth doing to support that other application.
Other projects can ignore time consuming regression tests by raw exposure to a great number of tech-savvy users, with the ability and will to submit great bug reports (ex:Linux).
In the case of wine, they would probably do better by being defensive against regressions, since application support is everything in a project like this. Possibly they could get the application maintainers in the process, as to force new changes to pass all applications' checks, or at least those made by the application maintainers that care.
With the existing process I think that a somewhat complete free replacement for the win32 API, assuming this is the goal of the project, will remain a very far goal. But I hope I am either wrong, or if I am right that they will do something about it.
http://bugs.winehq.org/show_bug.cgi?id=11188
Zakhar eze@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eze@free.fr
--- Comment #58 from Zakhar eze@free.fr 2008-11-27 17:31:45 --- You are probably right Claudio. But they might also be some cases where such modifications will make some program work and break others with no possibility ever to have all the programs working at the same time... because it is not the same system as Windows and at some point, behaviours are different and can't be masqueraded !
In such a case, you would have to develop an even more complicated routine to say: - do you want I/O completion ? Then you have a parameter in you program, such as:
wine --force-IOCompletion
...or something similar.
All that could easily become very very complicated if you start multiplying such parameters. So at a certain time you would have to decide to drop support for some programs.
Remember that even Microsoft has to drop support for very very old ill behaved MS-DOS or early Windows programs. And in this case, as it is not open source, you have no solution!
When that time come, your only option is to compile by yourself!
Thanks god Wine is open source, so you can still do it. And it is not that difficult to compile Wine ;-) ... it's just a bit long, and you have to be careful to type the right commands.
For those who can read French, here is a tutorial to compile Wine on Ubuntu 8.10 -Intrepid- 64 bits http://forum.ubuntu-fr.org/viewtopic.php?id=271622 (see post #4)
[But I agree with you: Warcraft 3 is not THAT old... and should still be on the support list, with no need to recompile Wine!]
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #59 from luke16 luke16@gmail.com 2008-12-05 20:32:20 --- Wine 1.1.10 seems to alleviate this problem. I just saved 10 times in a row without crashing, whereas before, I would have been extremely lucky just to get one. Out of about 15 saves, it has only crashed once so far, and that was basically just a screen blank. I could still here the music and fighting sfx in the background, just no video.
http://bugs.winehq.org/show_bug.cgi?id=11188
anomalydetected@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anomalydetected@gmail.com
--- Comment #60 from anomalydetected@gmail.com 2008-12-08 01:11:02 --- (In reply to comment #59)
Wine 1.1.10 seems to alleviate this problem. I just saved 10 times in a row without crashing, whereas before, I would have been extremely lucky just to get one. Out of about 15 saves, it has only crashed once so far, and that was basically just a screen blank. I could still here the music and fighting sfx in the background, just no video.
I still have the problem in 1.1.10. Crashes at almost any attempt to save. Using a patched 1.1.9 works great for me. Haven't tried applying the same patch to 1.1.10, but expect it will work just as well.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #61 from michal.modzel@gmail.com 2008-12-08 03:54:02 --- (In reply to comment #59)
Wine 1.1.10 seems to alleviate this problem. I just saved 10 times in a row without crashing, whereas before, I would have been extremely lucky just to get one. Out of about 15 saves, it has only crashed once so far, and that was basically just a screen blank. I could still here the music and fighting sfx in the background, just no video.
Well, it works for me:). I did not patched wine at all - just had my wine updated to 1.1.10. I saved successfully couple of times in a row, whereas before it was completely impossible.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #62 from luke16 luke16@gmail.com 2008-12-08 12:14:31 ---
Well, it works for me:). I did not patched wine at all - just had my wine updated to 1.1.10. I saved successfully couple of times in a row, whereas before it was completely impossible.
Make sure you thoroughly check this. In a large 1 vs 11 cpu game, saving at first may work if you save it at the very start, but then if you wait a few minutes until saving again, it starts consistently crashing again. I had to learn this the hard way.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #63 from John M. Drescher drescherjm@gmail.com 2008-12-08 12:19:31 --- I have seen that many factors effect this. I mean at one time I had a few hours of stable saves when I changed the video resolution only to have the crash again on my next start of the game. With the patch I have never had it crash. However I have not played much since then because of a video card (nvidia ti 4200) gone bad and my motherboard not working in opengl with a new nvidia agp card. I got a new system over the weekend so this problem should be gone and I should be able to test again.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #64 from Michal Illich list@illich.cz 2008-12-12 18:55:14 --- I confirm this bug is still present in 1.1.10 - for me every attempt to save crashes the game (actually the process is still running, music is playing for a while, but the application window is lost and the game is not saved either). -- tried under Fedora 10, wine-1.1.10-1.fc10.i386.
http://bugs.winehq.org/show_bug.cgi?id=11188
Jaymes jaymes.tru@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jaymes.tru@gmail.com
--- Comment #65 from Jaymes jaymes.tru@gmail.com 2008-12-20 01:54:23 --- I can confirm this bug exists as well, but it didn't happened until a few saves in. Does the IoCompletion patch fix things ? If so, is there a current patch for 1.1.10?
wine.1.1.10 - Ubuntu 8.10
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #66 from John M. Drescher drescherjm@gmail.com 2008-12-20 02:42:26 --- The same patch works for 1.1.10. I have not tested it extensively though.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #67 from Jaymes jaymes.tru@gmail.com 2008-12-20 03:06:00 --- (In reply to comment #66)
The same patch works for 1.1.10. I have not tested it extensively though.
I reviewed the patch and the portion of code it changes and it doesn't seem to match up (I am no pro in understanding diff files though, so I could be mistaken).
It appears my save crash only occurs when I change levels. If I save when I start a new level, I can save whenever during ONLY that one level. When I complete the level and go to the next one and attempt to save is when the crash occurs:
Exception 0xC0000005 (ACCESS_VIOLATION) @ 0073:7EF94A52
The instruction at 0x7EF94A52 reference memory at 0x0BC20090. The memory could not be 'written'.
Anyways... a temporary work around is to just complete the level, exit out of the level and then select the new level from the campaign list. All your hero data is still maintained (items, level, etc).
I'll try this patch upon hearing back from John Drescher.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #68 from John M. Drescher drescherjm@gmail.com 2008-12-20 09:36:43 --- It built fine for me under gentoo x86_64 with the same patch applied as I have used since wine-1.1.2. This is the same patch that is from the link. Any gentoo user can download an ebuild from
http://github.com/drescherjm/jmdgentoooverlay/tree/master/app-emulation/wine
or use the wiki link
http://github.com/drescherjm/jmdgentoooverlay/wikis
to add this to layman so that you can get the updated builds when new versions come out.
John
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #69 from Bill Vanderpol william.vanderpol@gmail.com 2008-12-29 13:32:44 --- Yep. The patch fixes the problem for me on x86 Gentoo, Wine version 1.1.11.
http://bugs.winehq.org/show_bug.cgi?id=11188
Jason Heeris jason.heeris@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jason.heeris@gmail.com
--- Comment #70 from Jason Heeris jason.heeris@gmail.com 2009-01-06 22:57:45 --- This patch worked for a while, but brought up other problems...
My system: NEC Versa M540 Pentium M, running fresh install Debian Lenny with the kernel in linux-image-2.6.26-1-686 (2.6.26-12) package.
Video setup is ATI Radeon FGL using fglrx drivers 8-7-3. I run WC3 with the '-opengl' option usually (but it makes no difference to this problem).
I experienced the same problem using the Debian packaged wine 1.1.11 (from Lamaresh rep). So:
1. I downloaded the source, and compiled two separate versions: one without any changes, and one with only the patch. I had to remove the fglrx-glx package to compile it, and reinstall it after.
2. Running wine 1.1.11 without any changes gave me the crash detailed above when I try to save. In game videos and cut scenes work fine, it's just saving that crashes.
3. Running wine 1.1.11 WITH the IO completion patch allowed me to save, BUT when I get to the end of, say, the first (Human) mission wine crashes with a similar error. By end, I mean: when my minions kill the last enemy, triggering the completion of the main quest, I get the error message below.
Error message:
---- war3
This application has encountered a critical error:
FATAL ERROR!
Program: C:\Program Files\Warcraft III\war3.exe Exception: 0xC0000005 (ACCESS_VIOLATION) at 0073:6F6D211D
The instruction at '0x6F6D211D' referenced memory at '0x083600E8'. The memory could not be 'read'.
Press OK to terminate the application. ----
4. If I save right before this point, re-install the unpatched wine, and commence playing from the saved game, there is no error. The game cuts to a video scene and then the mission ends. But then when I try to save... same crash as before.
There is no difference if I: enable/disable sound (via winecfg), run with/without '-opengl', change video settings/resolution in any way or rename the 'Movies' directory in the program directory.
I didn't want to clutter the thread with several Mb of compile logs, etc, but I'd be happy to attach any other info that's useful (or learn how to use winedbg and attach that).
(I typed this out pretty quickly, so please let me know if I've omitted something obvious.)
Cheers, Jason
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #71 from Jason Heeris jason.heeris@gmail.com 2009-01-07 01:46:00 --- I forgot to add: because my screen res is 1280x800, I need to emulate a virtual desktop in wine to run WC3, otherwise the image is garbled. (Incidentally, if anyone knows a way around this, I'd love to hear it.)
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #72 from Jason Heeris jason.heeris@gmail.com 2009-01-07 01:54:32 --- Please forgive my rapid repeat posting... :/
I just discovered that if I load the game as before, using the patched version of wine, and then delay the actions that cause the end of the mission by a few seconds, I can then go and complete the mission and the game progresses as normal. The saved game is at a point where it only takes about three seconds to complete the mission, and it seems that if I don't have a sufficient delay between loading the game and WC3 trying to load a movie, I get the crash.
In other words, sending my units for a light jog around the village seems to work.
...
Jason
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #73 from luke16 luke16@gmail.com 2009-01-07 02:03:28 --- (In reply to comment #72)
complete the mission, and it seems that if I don't have a sufficient delay between loading the game and WC3 trying to load a movie, I get the crash.
Trying to load a movie? I thought this happened at the end of the first human mission right after you kill the boss raider? No cinematic movies play after that.
(In reply to comment #71)
I forgot to add: because my screen res is 1280x800, I need to emulate a virtual desktop in wine to run WC3, otherwise the image is garbled. (Incidentally, if anyone knows a way around this, I'd love to hear it.)
Do you have the game set up to use exactly that resolution and nothing else?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #74 from Jason Heeris jason.heeris@gmail.com 2009-01-07 02:14:41 --- (In reply to comment #73)
(In reply to comment #72)
complete the mission, and it seems that if I don't have a sufficient delay between loading the game and WC3 trying to load a movie, I get the crash.
Trying to load a movie? I thought this happened at the end of the first human mission right after you kill the boss raider? No cinematic movies play after that.
After my units kill the slave master (the orc boss), there's a quick cut-scene with the villagers and Prince Fabio (I mean Arthas).
(In reply to comment #71)
I forgot to add: because my screen res is 1280x800, I need to emulate a virtual desktop in wine to run WC3, otherwise the image is garbled. (Incidentally, if anyone knows a way around this, I'd love to hear it.)
Do you have the game set up to use exactly that resolution and nothing else?
There is no 1280x800 resolution available in WC3, so I use 1024x768, and that's the size my virtual desktop is set to.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #75 from nop nopnopzero@gmail.com 2009-01-07 03:12:44 --- (In reply to comment #74)
(In reply to comment #73)
(In reply to comment #72)
complete the mission, and it seems that if I don't have a sufficient delay between loading the game and WC3 trying to load a movie, I get the crash.
Trying to load a movie? I thought this happened at the end of the first human mission right after you kill the boss raider? No cinematic movies play after that.
After my units kill the slave master (the orc boss), there's a quick cut-scene with the villagers and Prince Fabio (I mean Arthas).
I don't know if movie playback is now supported in Warcraft III, you should rename the movie directory to disable the cut scenes.
mv Movies Movies.bak
When you want to watch the cut scenes, you might use mplayer or xine. see also http://appdb.winehq.org/objectManager.php?sClass=version&iId=3126&iT... "After installing the game, its highly recommended that you browse to your Warcraft III folder..."
(In reply to comment #71)
I forgot to add: because my screen res is 1280x800, I need to emulate a virtual desktop in wine to run WC3, otherwise the image is garbled. (Incidentally, if anyone knows a way around this, I'd love to hear it.)
Do you have the game set up to use exactly that resolution and nothing else?
There is no 1280x800 resolution available in WC3, so I use 1024x768, and that's the size my virtual desktop is set to.
You should use -opengl. Is the check box 'fullscreen' is ticked into Warcraft III video options ?
About your garbled image, I have experienced a bug with the textures each time I minimize/switch (alt-tab) the Warcraft III game. There is a workaround fix to prevent the window to be minimized. http://bugs.winehq.org/show_bug.cgi?id=13547
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #76 from Jason Heeris jason.heeris@gmail.com 2009-01-07 03:29:30 --- (In reply to comment #75)
I don't know if movie playback is now supported in Warcraft III, you should rename the movie directory to disable the cut scenes.
It works fine in the unpatched wine, but I tried the rename trick anyway with no success. See comment #70.
There is no 1280x800 resolution available in WC3, so I use 1024x768, and that's the size my virtual desktop is set to.
You should use -opengl. Is the check box 'fullscreen' is ticked into Warcraft III video options ?
I use the '-opengl' flag, and it doesn't work fullscreen with or without fullscreen set in WC3. The image is garbled right from the start, whether or not I change windows.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #77 from Jason Heeris jason.heeris@gmail.com 2009-01-07 03:32:54 --- (In reply to comment #76)
(In reply to comment #75)
You should use -opengl. Is the check box 'fullscreen' is ticked into Warcraft III video options ?
I use the '-opengl' flag, and it doesn't work fullscreen with or without fullscreen set in WC3. The image is garbled right from the start, whether or not I change windows.
Wait, what 'fullscreen' checkbox? I don't see any checkbox.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #78 from nop nopnopzero@gmail.com 2009-01-07 03:43:39 --- (In reply to comment #77)
(In reply to comment #76)
(In reply to comment #75)
You should use -opengl. Is the check box 'fullscreen' is ticked into Warcraft III video options ?
I use the '-opengl' flag, and it doesn't work fullscreen with or without fullscreen set in WC3. The image is garbled right from the start, whether or not I change windows.
Wait, what 'fullscreen' checkbox? I don't see any checkbox.
Errr... you are right. Let me check it when I could access to my Linux box.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #79 from luke16 luke16@gmail.com 2009-01-07 12:20:13 --- (In reply to comment #74)
After my units kill the slave master (the orc boss), there's a quick cut-scene with the villagers and Prince Fabio (I mean Arthas).
Technically that's not a movie. I thought you meant one of the pre-drawn cinematics.
(In reply to comment #71)
I forgot to add: because my screen res is 1280x800, I need to emulate a virtual desktop in wine to run WC3, otherwise the image is garbled. (Incidentally, if anyone knows a way around this, I'd love to hear it.)
Do you have the game set up to use exactly that resolution and nothing else?
There is no 1280x800 resolution available in WC3, so I use 1024x768, and that's the size my virtual desktop is set to.
You can set war3's res to whatever you want it to. Open up a terminal, type 'regedit' and then from there go to 'current_user' > software > Blizzard > war3
video, and then notice the settings that say either 'resheight' or
'reswidth'. Set those to 1280 and 800. Make sure the numbers are in dec, not hex.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #80 from Jason Heeris jason.heeris@gmail.com 2009-01-07 16:36:44 --- (In reply to comment #79)
(In reply to comment #74)
After my units kill the slave master (the orc boss), there's a quick cut-scene with the villagers and Prince Fabio (I mean Arthas).
Technically that's not a movie. I thought you meant one of the pre-drawn cinematics.
Ah... no, just the cut-scene then.
(In reply to comment #71)
You can set war3's res to whatever you want it to. Open up a terminal, type 'regedit' and then from there go to 'current_user' > software > Blizzard > war3
video, and then notice the settings that say either 'resheight' or
'reswidth'. Set those to 1280 and 800. Make sure the numbers are in dec, not hex.
Great! It worked perfectly. Thanks :)
-Jason
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #81 from Claudio sick_soul@yahoo.it 2009-01-07 17:29:09 --- btw, this is a regression. wine-0.9.24 good, wine-0.9.52 bad.
Should someone have time to do a regression test:
http://wiki.winehq.org/RegressionTesting
Otherwise I'll do it, eventually.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #82 from John M. Drescher drescherjm@gmail.com 2009-01-07 17:34:15 --- Isn't the patch the regression test? I mean at some point someone added IOCP to wine and that having IOCP enabled in wine causes this bug.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #83 from John M. Drescher drescherjm@gmail.com 2009-01-07 17:37:46 --- Sorry about the wording. I am having a bad day.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #84 from John M. Drescher drescherjm@gmail.com 2009-01-07 18:00:42 --- I looked at the code for 0.9.24 and IOCP is not enabled:
HANDLE WINAPI CreateIoCompletionPort(HANDLE hFileHandle, HANDLE hExistingCompletionPort, ULONG_PTR CompletionKey, DWORD dwNumberOfConcurrentThreads) { FIXME("(%p, %p, %08lx, %08x): stub.\n", hFileHandle, hExistingCompletionPort, CompletionKey, dwNumberOfConcurrentThreads); SetLastError(ERROR_CALL_NOT_IMPLEMENTED); return NULL; }
It would be interesting to see what version added this function and see if that does indeed cause the crash.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #85 from John M. Drescher drescherjm@gmail.com 2009-01-07 18:12:10 --- I find that IOCP was added in 0.9.39.
HANDLE WINAPI CreateIoCompletionPort(HANDLE hFileHandle, HANDLE hExistingCompletionPort, ULONG_PTR CompletionKey, DWORD dwNumberOfConcurrentThreads) { NTSTATUS status; HANDLE ret = 0;
TRACE("(%p, %p, %08lx, %08x)\n", hFileHandle, hExistingCompletionPort, CompletionKey, dwNumberOfConcurrentThreads);
if (hExistingCompletionPort && hFileHandle == INVALID_HANDLE_VALUE) { SetLastError( ERROR_INVALID_PARAMETER); return NULL; }
if (hExistingCompletionPort) ret = hExistingCompletionPort; else { status = NtCreateIoCompletion( &ret, IO_COMPLETION_ALL_ACCESS, NULL, dwNumberOfConcurrentThreads ); if (status != STATUS_SUCCESS) goto fail; }
if (hFileHandle != INVALID_HANDLE_VALUE) { FILE_COMPLETION_INFORMATION info; IO_STATUS_BLOCK iosb;
info.CompletionPort = ret; info.CompletionKey = CompletionKey; status = NtSetInformationFile( hFileHandle, &iosb, &info, sizeof(info), FileCompletionInformation ); if (status != STATUS_SUCCESS) goto fail; }
return ret;
fail: if (ret && !hExistingCompletionPort) CloseHandle( ret ); SetLastError( RtlNtStatusToDosError(status) ); return 0; }
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #86 from Jason Heeris jason.heeris@gmail.com 2009-01-08 05:25:34 --- Okay, turns out I was wrong about the delay being needed. I get the crash (exactly the same) at the end of the second mission, just after defeating the slave master, despite not having saved or loaded a game within several minutes.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #87 from joaopa jeremielapuree@yahoo.fr 2009-01-08 06:20:32 --- The first thing to do is a real regression test to find the real bad commit: http://wiki.winehq.org/RegressionTesting
If the bad commit is 6310819afb0ac294573551c2117f636ed8367ccc actually, then you need to write tests to see what is wrong in this patch.
Reporting again and again that it is broken does not help.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #88 from joaopa jeremielapuree@yahoo.fr 2009-01-08 06:26:33 --- Can an administrator put the link of the demo at the URL place, please?
Thanks
http://www.mofunzone.com/download_games/warcraft_iii_reign_of_chaos.shtml
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #89 from John M. Drescher drescherjm@gmail.com 2009-01-08 06:48:22 --- The biggest problem with regression testing is that the game does not exhibit this bug all the time so it make take 1 hour or longer of playing to hit this bug or you may hit it on the first save. I simply do not have the time to find out. Too busy at the day job.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #90 from Austin English austinenglish@gmail.com 2009-01-08 09:49:56 --- (In reply to comment #88)
Can an administrator put the link of the demo at the URL place, please?
Thanks
http://www.mofunzone.com/download_games/warcraft_iii_reign_of_chaos.shtml
Does the demo have the same problem?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #91 from anomalydetected@gmail.com 2009-01-08 15:02:13 --- (In reply to comment #70)
This patch worked for a while, but brought up other problems...
...
- Running wine 1.1.11 without any changes gave me the crash detailed above
when I try to save. In game videos and cut scenes work fine, it's just saving that crashes. 3. Running wine 1.1.11 WITH the IO completion patch allowed me to save, BUT when I get to the end of, say, the first (Human) mission wine crashes with a similar error. By end, I mean: when my minions kill the last enemy, triggering the completion of the main quest, I get the error message below. Error message:
war3 This application has encountered a critical error: FATAL ERROR! Program: C:\Program Files\Warcraft III\war3.exe Exception: 0xC0000005 (ACCESS_VIOLATION) at 0073:6F6D211D The instruction at '0x6F6D211D' referenced memory at '0x083600E8'. The memory could not be 'read'. Press OK to terminate the application.
I had a very similar experience, where I would get end-of-level crashes like the above even after patching (though normal saves worked). Believe it or not, it turned out to be a genuine memory error. Go figure.
Memtest86 confirmed there was any issue after running only a few minutes. Turned out to be that my bios was improperly detecting the dram timings & bus speed for my ram. Manually setting them to the correct values in BIOS made memtest86 happy and war3 never crashed again.
What tipped me off that this was an actual hardware issue was that I tried running war3 on a windows partition as a test and had the same problem, so it definitely wasn't wine related.
So WITH the IOCP patch 8368, I never crash in Wine 1.1.7 - 1.1.12. WITHOUT the patch I almost always crash when trying to save.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #92 from Claudio sick_soul@yahoo.it 2009-01-09 16:23:56 --- Created an attachment (id=18602) --> (http://bugs.winehq.org/attachment.cgi?id=18602) backport of 793453f768025789f791edbcee9299b4c5d73882 for versions around 0.9.47
I am doing the regression test; it is in fact difficult to do, because the bug does not happen at each save attempt, but I am playing two scenarios with 32 save attempts pro scenario for each checked revision, so I hope to produce a good result anyway.
It would help if someone else does this.
In revisions between 0.9.46 to 0.9.49 a bug prevents a single player scenario from being loaded (the blue progress bar stops around 80-90% and war3.exe must be kill -9ed).
Doing a reverse regression test I got
793453f768025789f791edbcee9299b4c5d73882 ntdll: Make async I/O functions generate completion messages.
Backporting of this change may be necessary to be able to do a regression test for the original issue. I attach the already backported change for versions around 0.9.47.
This attachment is _not_ a workaround or a patch for the original issue.
This is only something useful for someone doing a real regression test, and happens to end up checking revisions around 0.9.47.
Again, I am doing one, but since the issue is not trivial to reproduce, having another independent result would help hugely.
http://bugs.winehq.org/show_bug.cgi?id=11188
Claudio sick_soul@yahoo.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18602|0 |1 is obsolete| |
--- Comment #93 from Claudio sick_soul@yahoo.it 2009-01-09 16:57:39 --- (From update of attachment 18602) the backport is crap. It is not so easy. I need to check the server_protocol.h in more detail.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #94 from Claudio sick_soul@yahoo.it 2009-01-09 17:27:14 --- Created an attachment (id=18604) --> (http://bugs.winehq.org/attachment.cgi?id=18604) backport of 793453f768025789f791edbcee9299b4c5d73882 for versions around 0.9.47 that actually works
this is a backport of 793453f768025789f791edbcee9299b4c5d73882 that seems to actually work.
It consists of
c702a91a3ca605637577281f78a1dc61dd067e06 27cb7c72747507d495e3547d920b3330e24e1da9 793453f768025789f791edbcee9299b4c5d73882
applied in succession, but disregarding tests and protocol version. Again, this is just to help with regression testing.
http://bugs.winehq.org/show_bug.cgi?id=11188
Zakhar eze@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|eze@free.fr |
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #95 from joaopa jeremielapuree@yahoo.fr 2009-01-10 01:16:40 --- Austin, yes the demo has the same problem.
http://bugs.winehq.org/show_bug.cgi?id=11188
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.mofunzone.com/dow | |nload_games/warcraft_iii_rei | |gn_of_chaos.shtml Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #96 from Jason Heeris jason.heeris@gmail.com 2009-01-10 11:29:47 --- I've been trying to do a proper regression test, but between the half-hour compile time, various revisions of wine failing to compile*, and the relatively frequent hard-reboots it's beginning to get a little trying. I'll keep at it, since I can reproduce this bug pretty somewhat reliably, but I'm not sure how far I'll get.
Memtest returned clean, by the way.
(*Apparently git-bisect doesn't cope too well with the skip command either, so there might be nothing for it.)
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #97 from Claudio sick_soul@yahoo.it 2009-01-10 16:53:33 --- I finished my regression test. I got:
477582401b9a7b6baf188a788b9972c12495c51a is first bad commit commit 477582401b9a7b6baf188a788b9972c12495c51a Author: Andrey Turkin andrey.turkin@gmail.com Date: Tue Sep 18 00:00:45 2007 +0400
server: Implement server-side completion queues and operations on them.
:040000 040000 ab2c6bf45138e22c62cfafcaadcefd57bd9407d1 7d4520d246d44a63d09bcae4e29033dc05a2955d M dlls :040000 040000 482b39d1eff431320098ac137f8c99822b08d215 062636a29d0853fcce810e7530d0414d2fab96b1 M include :040000 040000 ce0b55aa8f8649c0d37504e474656b0de8a5b0be 3df6965ca1d3adb561422917cc1455fa79f056f2 M server
I could progress much faster as soon as I realized that I could load a saved game I have and be able to reproduce the problem reliably on the first subsequent save attempt.
During this test I had to change the concept of "BAD revision" a little in progress, as different wine versions react to the problem differently.
In newer wine versions, a failed attempt to save got me the war3 memory protection error dialog.
In older wine versions around 0.9.50 a failed attempt to save caused the process to just block forever.
In even older wine versions, between 0.9.45 and 0.9.46, a failed attempt to save caused a 0 length file to be created instead of the circa 2MB game file, and the game did not crash at all, but instead of turning the text 'green' to indicate success, the dialog text with the game's filename turned Red, and the game went on (but with a failed save).
I'll attach the bisection log, the saved game with which I could reliably reproduce the problem, and the output obtained with WINEDEBUG=+relay of the failed attempt to save. I generated this by attaching gdb to the process just before saving, and then using call putenv("WINEDEBUG=+relay"), otherwise the output generation was simply too huge.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #98 from Claudio sick_soul@yahoo.it 2009-01-10 16:57:07 --- Created an attachment (id=18623) --> (http://bugs.winehq.org/attachment.cgi?id=18623) git bisect log
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #99 from Claudio sick_soul@yahoo.it 2009-01-10 17:01:37 --- Created an attachment (id=18624) --> (http://bugs.winehq.org/attachment.cgi?id=18624) failed save attempt: WINEDEBUG=+relay gzipped output for revision 909f7ffcb951fc34
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #100 from Claudio sick_soul@yahoo.it 2009-01-10 17:08:36 --- I uploaded the savegame used to reliably reproduce the problem, since it is too big to attach.
http://www.niceties.it/cla9.w3z
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #101 from joaopa jeremielapuree@yahoo.fr 2009-01-10 17:19:53 --- Claudio,
did you check that reverting the bad commit fixes the bug?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #102 from Claudio sick_soul@yahoo.it 2009-01-10 22:20:08 --- (In reply to comment #101)
Claudio,
did you check that reverting the bad commit fixes the bug?
Yes. I checked with my cla9.w3z with latest wine, and I got the usual memory protection error dialog.
I reverted the bad commit in latest wine, solving a moderate amount of merge conflicts, and the bug goes away.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #103 from joaopa jeremielapuree@yahoo.fr 2009-01-11 02:10:18 --- Then, a trace debug with WINEDEBUG=+sync,+ntdll will be useful.
Can an administrator write the Turkin's email adress in the CC place to advertise him that he caused a regression?
Thanks
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #104 from Claudio sick_soul@yahoo.it 2009-01-11 06:17:28 --- (In reply to comment #103)
Then, a trace debug with WINEDEBUG=+sync,+ntdll will be useful.
Isn't WINEDEBUG=+relay a superset of that? If it is, then the existing attachment #18624 should be good:
http://bugs.winehq.org/attachment.cgi?id=18624
It is readable since it starts exactly at the right moment. It is somewhat longer than needed, but I wanted to be sure not to exclude anything important.
But if +relay is not a superset of "+sync,+ntdll", just tell me and I'll do another run.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #105 from joaopa jeremielapuree@yahoo.fr 2009-01-11 07:29:41 --- As you said, with the +relay debug channel, there are tons of useless informations. It is hard to read.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #106 from Claudio sick_soul@yahoo.it 2009-01-11 07:48:51 --- Created an attachment (id=18640) --> (http://bugs.winehq.org/attachment.cgi?id=18640) first 255 lines from attachment 18624
I'll do another run then, but in the meantime I attach the first 255 lines from attachment 18624, which I find easy enough to read, and should have all interesting meat.
http://bugs.winehq.org/show_bug.cgi?id=11188
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.turkin@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #107 from Claudio sick_soul@yahoo.it 2009-01-14 07:29:33 --- Created an attachment (id=18692) --> (http://bugs.winehq.org/attachment.cgi?id=18692) result of reverting 477582401b9a7b6baf188a788b9972c12495c51a in latest wine, with all conflicts resolved
This could spare time to people wanting to revert 477582401b9a7b6baf188a788b9972c12495c51a in latest wine for testing purposes.
This patch is the result of reverting 477582401b9a7b6baf188a788b9972c12495c51a with all direct and indirect conflicts resolved.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #108 from Jason Heeris jason.heeris@gmail.com 2009-01-15 05:08:57 --- Applying Claudio's reversion again works for me, but causes a crash shortly after loading this saved game:
http://www.heeris.id.au/wine_crash.w3z.bz2
Unfortunately, if I run wine with WINEDEBUG=+sync,+ntdll the crash simply doesn't happen, so I'm a bit baffled as to how to diagnose that.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #109 from Claudio sick_soul@yahoo.it 2009-01-15 05:34:20 --- (In reply to comment #108)
Applying Claudio's reversion again works for me, but causes a crash shortly after loading this saved game:
http://www.heeris.id.au/wine_crash.w3z.bz2
Unfortunately, if I run wine with WINEDEBUG=+sync,+ntdll the crash simply doesn't happen, so I'm a bit baffled as to how to diagnose that.
This is an unrelated issue, we should keep our focus on the save game failure issue here. If you have other crashes I think you'd better file a separate report. Basing on the information you submitted above in this same ticket, I suspect you are experiencing some other, unrelated problem.
For testing purposes (*ahem*) I played the whole original WC3 orc, human and undead campaigns using latest git with reverted 477582401b9a and did not experience any crash (I am of course playing with no bik movies).
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #110 from Jason Heeris jason.heeris@gmail.com 2009-01-15 06:26:33 --- (In reply to comment #109)
This is an unrelated issue, we should keep our focus on the save game failure issue here. If you have other crashes I think you'd better file a separate report. Basing on the information you submitted above in this same ticket, I suspect you are experiencing some other, unrelated problem.
But surely I can't file a bug against a patch/reversion that isn't actually in he source? It doesn't occur with any actual commit of the wine source that I've been able to try - it only occurs when I change the source to to fix the save game crash.
My point is that this fix seems to cause another problem to spring up, but I can't possibly know if it's only for me. That's why I posted the saved game.
If it's an unrelated case, though, I'll just have to wait until this thread results in source changes and file a new bug then.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #111 from Claudio sick_soul@yahoo.it 2009-01-15 10:29:22 --- I loaded your saved game, and nothing goes wrong. A short in-game cutscene is played, and then I am sent to the next mission.
Is it possible that you have a "dirty" source tree? I'd try something in the league of:
git clean -x -d -f git checkout -f
then apply the p1 patch and rebuid (from configure). Beware that all non-tracked files will be removed from your source tree.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #112 from Jason Heeris jason.heeris@gmail.com 2009-01-16 06:13:51 --- (In reply to comment #111)
git clean -x -d -f git checkout -f
There's a trick I didn't know about...
The crash remains, but if it's an unrelated problem, I'll just drop it.
http://bugs.winehq.org/show_bug.cgi?id=11188
Xavier Vachon xvachon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xvachon@gmail.com
--- Comment #113 from Xavier Vachon xvachon@gmail.com 2009-01-24 00:10:11 --- (In reply to comment #107)
Created an attachment (id=18692)
--> (http://bugs.winehq.org/attachment.cgi?id=18692) [details]
result of reverting 477582401b9a7b6baf188a788b9972c12495c51a in latest wine, with all conflicts resolved
This could spare time to people wanting to revert 477582401b9a7b6baf188a788b9972c12495c51a in latest wine for testing purposes.
This patch is the result of reverting 477582401b9a7b6baf188a788b9972c12495c51a with all direct and indirect conflicts resolved.
I am unable to patch my fresh git tree with your patch. Here is a condensated log of the patch process and the make command.
Running on Gentoo X64 and latest wine-git.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #114 from Jason Heeris jason.heeris@gmail.com 2009-01-24 02:47:41 --- (In reply to comment #113)
Check out Claudio's tip above to be sure you've got the latest source. Then have a look at include/wine/server_protocol.h.rej and it might only need some very simple manual patching (maybe the protocol version is not what patch expected).
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #115 from Andrey Turkin andrey.turkin@gmail.com 2009-01-24 08:55:39 --- Created an attachment (id=18955) --> (http://bugs.winehq.org/attachment.cgi?id=18955) fix for race condition
Actually, could you guys please try out this patch?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #116 from John M. Drescher drescherjm@gmail.com 2009-01-24 09:16:47 --- (In reply to comment #115)
Created an attachment (id=18955)
--> (http://bugs.winehq.org/attachment.cgi?id=18955) [details]
fix for race condition
Being a programmer, I think understand what is happening here. I apologize for being cranky a few weeks ago about this.
Actually, could you guys please try out this patch?
I will try to do this today.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #117 from John M. Drescher drescherjm@gmail.com 2009-01-24 10:08:45 --- (In reply to comment #100)
I uploaded the savegame used to reliably reproduce the problem, since it is too big to attach.
I am having trouble getting this to crash on my new quad core with wine-1.1.13 and no patches. Any tips on getting this to fail. If not I will try the old box.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #118 from Claudio sick_soul@yahoo.it 2009-01-24 12:33:38 --- (In reply to comment #117)
(In reply to comment #100)
I uploaded the savegame used to reliably reproduce the problem, since it is too big to attach.
I am having trouble getting this to crash on my new quad core with wine-1.1.13 and no patches. Any tips on getting this to fail. If not I will try the old box.
Same here. There were changes between 1.1.12 and 1.1.13 in ntdll, I am doing a reverse regression test to understand which already committed change is involved in fixing at least this testcase.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #119 from Andrey Turkin andrey.turkin@gmail.com 2009-01-24 13:05:33 --- I was able to reproduce this error with WC3 demo and current git, I just had to play a little to get a second level. This bug is caused by race condition, it means that it only occurs sometime in more or less random manner, when threads execute in specific order in time.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #120 from John M. Drescher drescherjm@gmail.com 2009-01-24 14:49:50 ---
I am having trouble getting this to crash on my new quad core with wine-1.1.13 and no patches. Any tips on getting this to fail. If not I will try the old box.
Same here. There were changes between 1.1.12 and 1.1.13 in ntdll, I am doing a reverse regression test to understand which already committed change is involved in fixing at least this testcase.
Do you think there is any value of me going back to 1.1.12 and testing with and without your patch there? I probably will do that anyways since it will take less than 10 minutes to go back to 1.1.12.
BTW, for gentoo I have an ebuild with and without (set the wine-iocp-fix-race use flag) this patch for 1.1.13.
http://github.com/drescherjm/jmdgentoooverlay/tree/d474d160651a02fd1d7ec8c2e...
Instructions for adding this overlay to your system using layman are in the wiki link of the link above.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #121 from John M. Drescher drescherjm@gmail.com 2009-01-24 15:11:59 ---
Do you think there is any value of me going back to 1.1.12 and testing with and without your patch there? I probably will do that anyways since it will take less than 10 minutes to go back to 1.1.12.
Does not apply cleanly to 1.1.12 so I guess its back to testing 1.1.13.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #122 from Claudio sick_soul@yahoo.it 2009-01-24 17:35:32 --- (In reply to comment #119)
I was able to reproduce this error with WC3 demo and current git, I just had to play a little to get a second level. This bug is caused by race condition, it means that it only occurs sometime in more or less random manner, when threads execute in specific order in time.
I am going to test your patch heavily.
In the meantime, the reverse regression test with the 'cla9' saved game/testcase gave this result:
commit 4f74de5b366275ea522e269d29d2011a7b153e9e Author: Aleksey Bragin aleksey@reactos.org Date: Wed Dec 24 06:04:25 2008 +0400
ntdll: Fix buffer overread in RtlNumberOfSetBits.
with 4f74de5b366275ea522e269d29d2011a7b153e9e^ (the predecessor) the save attempt consistently fails. Applying 4f74de5b366275ea522e269d29d2011a7b153e9e makes the save succeed.
Repeatingly applying and reverting said commit causes the cla9 testcase to succeed and fail respectively, in a way to suggest that this change has at least an influence on this bug.
Can you put this information in correlation to the race condition?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #123 from Xavier Vachon xvachon@gmail.com 2009-01-24 17:46:40 --- (In reply to comment #122)
(In reply to comment #119)
I was able to reproduce this error with WC3 demo and current git, I just had to play a little to get a second level. This bug is caused by race condition, it means that it only occurs sometime in more or less random manner, when threads execute in specific order in time.
I am going to test your patch heavily.
In the meantime, the reverse regression test with the 'cla9' saved game/testcase gave this result:
commit 4f74de5b366275ea522e269d29d2011a7b153e9e Author: Aleksey Bragin aleksey@reactos.org Date: Wed Dec 24 06:04:25 2008 +0400
ntdll: Fix buffer overread in RtlNumberOfSetBits.with 4f74de5b366275ea522e269d29d2011a7b153e9e^ (the predecessor) the save attempt consistently fails. Applying 4f74de5b366275ea522e269d29d2011a7b153e9e makes the save succeed.
Repeatingly applying and reverting said commit causes the cla9 testcase to succeed and fail respectively, in a way to suggest that this change has at least an influence on this bug.
Can you put this information in correlation to the race condition?
So far with the race condition patch applied I have no save failures. Attempted 25 times to save so far with the last mission of The Frozen Throne expansion.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #124 from Claudio sick_soul@yahoo.it 2009-01-24 19:07:43 --- (In reply to comment #115)
Created an attachment (id=18955)
--> (http://bugs.winehq.org/attachment.cgi?id=18955) [details]
fix for race condition
Actually, could you guys please try out this patch?
by the way, could this race appear in other places, besides ntdll/file.c? I suppose dlls/ws2_32/socket.c could be affected as well.
The race condition fix appears to work for me, but I'll test more.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #125 from Claudio sick_soul@yahoo.it 2009-01-28 00:06:31 ---
I tested the race condition fix:
http://bugs.winehq.org/attachment.cgi?id=18955
and it works very well for me too.
With plain 1.1.13, I still had the problem, only in different places (for example, testcase cla9 did not trigger the issue).
By contrast, with the fix applied I could save consistently without problems.
http://bugs.winehq.org/show_bug.cgi?id=11188
Lukas Middendorf lukas.middendorf@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukas.middendorf@freenet.de
--- Comment #126 from Lukas Middendorf lukas.middendorf@freenet.de 2009-01-29 17:20:04 --- I also tried attachment 18955 patch against 1.1.13. Without the patch the game crashes, without I have played for several hours with many savegames and have not seen a single crash.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #127 from Lukas Middendorf lukas.middendorf@freenet.de 2009-01-29 17:26:54 --- (In reply to comment #126)
I also tried attachment 18955 [details] patch against 1.1.13. Without the patch the game crashes, without I have played for several hours with many savegames and have not seen a single crash.
It's of course "with" the patch that there has not been a single crash.
If the patch is not likely to cause other bugs and if it isn't just a hack, it should be added to git for 1.1.14
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #128 from Jason Heeris jason.heeris@gmail.com 2009-01-31 00:06:15 --- This patch also works for me, and doesn't cause the other, unrelated bug to surface as the other patches have done.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #129 from Lukas Middendorf lukas.middendorf@freenet.de 2009-02-01 07:44:01 --- Bug still exists in 1.1.14 and the race condition patch still works there.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #130 from anomalydetected@gmail.com 2009-02-10 10:29:57 --- (In reply to comment #129)
Bug still exists in 1.1.14 and the race condition patch still works there.
That's odd... SO FAR I don't experience the saving problem with a clean install of 1.1.4. I'm only on the 2nd campaign level, but I've purposely saved a few dozen times in different scenarios and with differnt filenames, etc - and no crashes!!! 1.1.2 (non-patched) would crash for me every 3rd save or so, and EVERY time in certain locations. Patching 1.1.2 made it work perfectly. Before I'd call this resolved for me, though, I'm going to play & save in a few more levels and in multiplayer etc. I'm still not convinced that it's totally better, but at the very least I see a notable improvement from previous version. Strangely, I don't see anything in the changelogs that would point to work on a related area, but you never know.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #131 from anomalydetected@gmail.com 2009-02-11 00:24:18 --- (In reply to comment #130)
(In reply to comment #129)
Bug still exists in 1.1.14 and the race condition patch still works there.
That's odd... SO FAR I don't experience the saving problem with a clean install of 1.1.4. I'm only on the 2nd campaign level, but I've purposely saved a few dozen times in different scenarios and with differnt filenames, etc - and no crashes!!! 1.1.2 (non-patched) would crash for me every 3rd save or so, and EVERY time in certain locations. Patching 1.1.2 made it work perfectly. Before I'd call this resolved for me, though, I'm going to play & save in a few more levels and in multiplayer etc. I'm still not convinced that it's totally better, but at the very least I see a notable improvement from previous version. Strangely, I don't see anything in the changelogs that would point to work on a related area, but you never know.
Okay, I take that back. I finally got it to crash while saving. Though I have to admit it was much harder than it used to be. Maybe just coincidental, but formerly (1.1.2) it used to crash with almost every save, now with 1.1.4 I had to work at it awhile.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #132 from John M. Drescher drescherjm@gmail.com 2009-02-11 06:54:54 --- I assume you mean 1.1.14 and 1.1.12 instead of 1.1.4 and 1.1.2. Is that correct?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #133 from anomalydetected@gmail.com 2009-02-11 21:50:46 --- (In reply to comment #132)
I assume you mean 1.1.14 and 1.1.12 instead of 1.1.4 and 1.1.2. Is that correct?
Yes, 1.1.12 and 1.1.14. Pardon my momentary mental lapse.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #134 from luke16 luke16@gmail.com 2009-03-10 17:51:11 --- So now that there is a known good patch available, what does it take to get it automatically incorporated into wine so that wine doesn't have to be made from source every release? Does wine even typically build patches for single applications into it, or does something else need to be done in order to fix this bug?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #135 from Austin English austinenglish@gmail.com 2009-03-11 12:10:29 --- (In reply to comment #134)
So now that there is a known good patch available, what does it take to get it automatically incorporated into wine so that wine doesn't have to be made from source every release? Does wine even typically build patches for single applications into it, or does something else need to be done in order to fix this bug?
A testcase would help. Patches are actually normally sent to fix a single application. The problem is, we don't want to break a different one in the process. A testcase showing how windows does it allows us to know it's the right behavior.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #136 from John M. Drescher drescherjm@gmail.com 2009-03-11 12:15:40 --- I don't believe this bug affects only wc3. I mean I would expect "a race condition in IOCP file writing" to affect other applications.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #137 from Lukas Middendorf lukas.middendorf@freenet.de 2009-03-11 13:21:14 --- (In reply to comment #135)
A testcase would help. Patches are actually normally sent to fix a single application. The problem is, we don't want to break a different one in the process. A testcase showing how windows does it allows us to know it's the right behavior.
Isn't it the problem with race conditions, that they can not be tested reproducibly?
And even if the patch does not exactly reproduce windows behaviour, it is better to have it wrong all the time than only sometimes.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #138 from luke16 luke16@gmail.com 2009-03-24 18:01:13 --- Since applying the patch, I haven't experienced any crashes while playing the game or saving. However, after logging on to battlenet, then going to the chat screen, I get a crash with an error message saying that memory could not be read. This happened three times in a row so far. It takes a while (~2-3 minutes) on the chat screen until it happens. This is with the recent 1.23 warcraft III: TFT patch and the latest wine. Does anybody else encounter this?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #138 from luke16 luke16@gmail.com 2009-03-24 18:01:13 --- Since applying the patch, I haven't experienced any crashes while playing the game or saving. However, after logging on to battlenet, then going to the chat screen, I get a crash with an error message saying that memory could not be read. This happened three times in a row so far. It takes a while (~2-3 minutes) on the chat screen until it happens. This is with the recent 1.23 warcraft III: TFT patch and the latest wine. Does anybody else encounter this?
--- Comment #139 from anomalydetected@gmail.com 2009-03-24 23:39:06 --- Yes, this is new behavior since the recently released, mandatory 1.23 update for warcraft 3 / battle.net. There is a bug already created for it. Please continue discussion on that topic here: http://bugs.winehq.org/show_bug.cgi?id=17809
http://bugs.winehq.org/show_bug.cgi?id=11188
Torsten Schönfeld kaffeetisch@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaffeetisch@gmx.de
--- Comment #138 from luke16 luke16@gmail.com 2009-03-24 18:01:13 --- Since applying the patch, I haven't experienced any crashes while playing the game or saving. However, after logging on to battlenet, then going to the chat screen, I get a crash with an error message saying that memory could not be read. This happened three times in a row so far. It takes a while (~2-3 minutes) on the chat screen until it happens. This is with the recent 1.23 warcraft III: TFT patch and the latest wine. Does anybody else encounter this?
--- Comment #139 from anomalydetected@gmail.com 2009-03-24 23:39:06 --- Yes, this is new behavior since the recently released, mandatory 1.23 update for warcraft 3 / battle.net. There is a bug already created for it. Please continue discussion on that topic here: http://bugs.winehq.org/show_bug.cgi?id=17809
http://bugs.winehq.org/show_bug.cgi?id=11188
Torsten Schönfeld kaffeetisch@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaffeetisch@gmx.de
sheen toxmerguez@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |toxmerguez@yahoo.fr
--- Comment #138 from luke16 luke16@gmail.com 2009-03-24 18:01:13 --- Since applying the patch, I haven't experienced any crashes while playing the game or saving. However, after logging on to battlenet, then going to the chat screen, I get a crash with an error message saying that memory could not be read. This happened three times in a row so far. It takes a while (~2-3 minutes) on the chat screen until it happens. This is with the recent 1.23 warcraft III: TFT patch and the latest wine. Does anybody else encounter this?
--- Comment #139 from anomalydetected@gmail.com 2009-03-24 23:39:06 --- Yes, this is new behavior since the recently released, mandatory 1.23 update for warcraft 3 / battle.net. There is a bug already created for it. Please continue discussion on that topic here: http://bugs.winehq.org/show_bug.cgi?id=17809
--- Comment #140 from sheen toxmerguez@yahoo.fr 2009-05-26 11:03:05 --- Saves Bug is present in 1.1.22 yet. The patch we can find here works like a charm. It does not seems to affect my others applications / games, maybe we should include it in wine 1.1.23.
http://bugs.winehq.org/show_bug.cgi?id=11188
Torsten Schönfeld kaffeetisch@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaffeetisch@gmx.de
sheen toxmerguez@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |toxmerguez@yahoo.fr
--- Comment #138 from luke16 luke16@gmail.com 2009-03-24 18:01:13 --- Since applying the patch, I haven't experienced any crashes while playing the game or saving. However, after logging on to battlenet, then going to the chat screen, I get a crash with an error message saying that memory could not be read. This happened three times in a row so far. It takes a while (~2-3 minutes) on the chat screen until it happens. This is with the recent 1.23 warcraft III: TFT patch and the latest wine. Does anybody else encounter this?
--- Comment #139 from anomalydetected@gmail.com 2009-03-24 23:39:06 --- Yes, this is new behavior since the recently released, mandatory 1.23 update for warcraft 3 / battle.net. There is a bug already created for it. Please continue discussion on that topic here: http://bugs.winehq.org/show_bug.cgi?id=17809
--- Comment #140 from sheen toxmerguez@yahoo.fr 2009-05-26 11:03:05 --- Saves Bug is present in 1.1.22 yet. The patch we can find here works like a charm. It does not seems to affect my others applications / games, maybe we should include it in wine 1.1.23.
--- Comment #141 from John M. Drescher drescherjm@gmail.com 2009-05-26 11:45:09 --- I believe the developers are waiting for someone to write a small test application for the iocp race that works in windows and causes the crash in wine.
http://bugs.winehq.org/show_bug.cgi?id=11188
Roman m01brv@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |m01brv@mail.ru
--- Comment #142 from Roman m01brv@mail.ru 2009-05-27 08:17:05 --- (In reply to comment #136)
I don't believe this bug affects only wc3. I mean I would expect "a race condition in IOCP file writing" to affect other applications.
I can confirm that this bug probably affects another 3D game, Deus Ex, http://appdb.winehq.org/objectManager.php?sClass=version&iId=3775.
The game saves created under wine (1.1.12 and 1.1.18, at least) do not contain previews of the environment and situation. These previews normally should be drawn in the load dialog, but for saves created under wine the preview squares are empty (whereas all windows saves previews are OK). The race condition patch fixed this for me - now all previews are saved correctly.
In this case this bug is not critical - I did not found other malfunctions in the saving functionality of Deus Ex.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #143 from Michael Monreal infernux@web.de 2009-05-27 10:04:46 --- (In reply to comment #142)
[...] do not contain previews of the environment [...]
I have not verified this, but I have seen the same issue (no save previews) in other game(s) before. If those are related the problem may occur more often than thought. I'm currently not sure which games exactly... Painkiller maybe?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #144 from Ken Sharp kennybobs@o2.co.uk 2009-05-27 11:16:16 --- Linking this to apps in the appdb will help (when known).
http://bugs.winehq.org/show_bug.cgi?id=11188
anjilslaire anjilslaire@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anjilslaire@hotmail.com
anakinpendragon anakinpendragon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anakinpendragon@gmail.com
--- Comment #145 from anjilslaire anjilslaire@hotmail.com 2009-08-23 03:57:29 --- Confirming this bug still exists, Ubuntu 9.04 i386, Wine 1.1.28
--- Comment #146 from anakinpendragon anakinpendragon@gmail.com 2009-09-26 10:59:37 --- Confirming this bug still exists, Mandriva 2009, Wine 1.1.30 AMD Atlhon 64 x2, video ATI Radeon HD 3200 .
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #147 from Tim lauxenburg@live.com 2009-10-02 20:41:14 --- Created an attachment (id=23886) --> (http://bugs.winehq.org/attachment.cgi?id=23886) Easy Fix for Crashes while Attempting to Save.
This will be my first submission on WineHQ/Bugzilla, so bear with me but...
There is a simple fix for the FATAL ERROR! crash some people encounter while trying to save in campaign mode. You just need to download one registry file (.reg) from:
ftp.blizzard.com/pub/war3/other/war3.reg
Add this to your Wine C: Drive, under Warcraft III. Next time you try to save in the game, it should save flawlessly.
This worked for me and I think it should work for anyone else.
Cheers.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #148 from anakinpendragon anakinpendragon@gmail.com 2009-10-03 11:15:01 --- (In reply to comment #147)
Created an attachment (id=23886)
--> (http://bugs.winehq.org/attachment.cgi?id=23886) [details]
Easy Fix for Crashes while Attempting to Save.
This will be my first submission on WineHQ/Bugzilla, so bear with me but...
There is a simple fix for the FATAL ERROR! crash some people encounter while trying to save in campaign mode. You just need to download one registry file (.reg) from:
ftp.blizzard.com/pub/war3/other/war3.reg
Add this to your Wine C: Drive, under Warcraft III. Next time you try to save in the game, it should save flawlessly.
This worked for me and I think it should work for anyone else.
Cheers.
Great! It work for me too, but i apply te war3.reg with regedit. When video work, the game will play perfect.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #149 from John M. Drescher drescherjm@gmail.com 2009-10-03 11:21:34 --- Have you rigorously tested this? I mean when I tested this with the unpatched wine sometimes it worked for hours before the first crash then other times it crashed on the first save. I ask because the registry file does not look like it has anything to do with saving files at all. Just some audio and video default settings.
Also is there documentation on the blizzard site that explains what these registry settings do?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #150 from John M. Drescher drescherjm@gmail.com 2009-10-03 11:23:50 --- I should have rephrased that to "when I tested this bug (not the new registry file) with the unpatched wine sometimes it worked for hours before"
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #151 from Thomas Benn sotis@gmx.net 2009-10-03 14:35:23 --- This link does not work for me. All I get is "Could not open data connection", even if I point at just ftp.blizzard.com
Am I the only one this happens to?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #152 from luke16 luke16@gmail.com 2009-10-03 14:40:31 --- The contents of the reg file are listed below if you can't access them from the site. I don't think they will do anything to help though. It looks like there is nothing but video and audio settings that are all configurable from war3 directly.
REGEDIT4
[HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III]
[HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III\Video]
"reswidth"=dword:00000280
"resheight"=dword:000001e0
"colordepth"=dword:00000010
"adapter"=dword:00000000
"refreshrate"=dword:0000003c
"gamma"=dword:0000001e
"modeldetail"=dword:00000000
"animquality"=dword:00000000
"texquality"=dword:00000000
"miplevel"=dword:00000001
"texcolordepth"=dword:00000010
"particles"=dword:00000000
"lights"=dword:00000000
"lockfb"=dword:00000001
"unitshadows"=dword:00000000
"occlusion"=dword:00000000
[HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III\Sound]
"provider"=dword:00000001
"positional"=dword:00000000
"environmental"=dword:00000000
"music"=dword:00000000
"musicvolume"=dword:00000041
"sfx"=dword:00000000
"sfxvolume"=dword:00000064
"ambient"=dword:00000000
"movement"=dword:00000000
"unit"=dword:00000000
"subtitles"=dword:00000000
"nomidi"=dword:00000000
"softwaremidi"=dword:00000001
"nosoundwarn"=dword:00000001
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #153 from Thomas Benn sotis@gmx.net 2009-10-04 00:52:50 --- Ok, I tested this. In Mission 5 of the humans (the timed defense of Hearthglen) I could NOT save at all, it would crash every time. Now, with the reg-edit I managed to save a whole 3 times. On the fourth, it crashed. I use wine 1.1.30, btw. I am going to try and finish the mission anyway to see if my problem that actually keeps me from playing at all (mission 6 wont start, see my post on the app-db for WC3 please) has by any chance been solved by the reg. I doubt it, but it's worth a shot.
http://bugs.winehq.org/show_bug.cgi?id=11188
Louigi Verona louigi.verona@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |louigi.verona@gmail.com
--- Comment #154 from Louigi Verona louigi.verona@gmail.com 2009-11-16 04:02:05 --- So, guys! Any update on solving this?
Because I am in a deadlock situation with Warcraft. If it were only saves I would have no problems not saving during the level and just playing the campaign through. But if I don't save, the game crashes within 20-30 minutes of playing anyway. So I HAVE to save since 20 minutes is not enough for playing through a standard campaign level, and saving crashes pretty often.
Also, note that in earlier levels of the game I can save many times and nothing happens. I actually started experiencing save problems later on in the human campaign, when I was playing in the North levels and Frostmourne level. Starting from that. Before that I saved heavily being afraid the game would crash and it was ok.
I see the patch is suggested, yet many people say it broke something else. So is it worth applying?
Also, how do I apply? I've read help as suggested, but did not understand fully. Do I have to save contents of the patch as in the link into the test file? How should I name this text file?
What if Wine doesn't compile? (simpler programms failed to compile for unknown reasons on my system, really. Wine is such a major thing i am not sure it will work). Will I loose all my Wine installed software?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #155 from luke16 luke16@gmail.com 2009-11-16 08:49:44 ---
Also, how do I apply? I've read help as suggested, but did not understand fully. Do I have to save contents of the patch as in the link into the test file? How should I name this text file?
What if Wine doesn't compile? (simpler programms failed to compile for unknown reasons on my system, really. Wine is such a major thing i am not sure it will work). Will I loose all my Wine installed software?
Your best bet is to follow the instructions from the "How to get Battle.net working?" section that is on the war3ft appdb page. That includes the save patch, along with other patches to get battlenet working. Make sure you do the apt-get build-dep wine command so that it will compile correctly. It shouldn't crash at all after that.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #156 from Louigi Verona louigi.verona@gmail.com 2009-12-05 04:11:45 ---
Your best bet is to follow the instructions from the "How to get Battle.net working?" section that is on the war3ft appdb page. That includes the save patch, along with other patches to get battlenet working. Make sure you do the apt-get build-dep wine command so that it will compile correctly. It shouldn't crash at all after that.
Tried it. Couldn't do the first step (hehe):
louigi@louigi-laptop:~$ git clone git://repo.or.cz/wine/warcraft3.git wine-war3Initialized empty Git repository in /home/louigi/wine-war3/.git/ fatal: The remote end hung up unexpectedly
http://bugs.winehq.org/show_bug.cgi?id=11188
Simon Simon80@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Simon80@gmail.com
--- Comment #157 from Simon Simon80@gmail.com 2009-12-30 23:10:34 --- (In reply to comment #71)
I forgot to add: because my screen res is 1280x800, I need to emulate a virtual desktop in wine to run WC3, otherwise the image is garbled. (Incidentally, if anyone knows a way around this, I'd love to hear it.)
Sorry for the off topic response, but if your driver is fglrx, you can add the following to your xorg.conf:
Section "Device" ... Option "CenterMode" "true" ... EndSection
This is documented in the man page for fglrx.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #158 from Roman m01brv@mail.ru 2010-05-31 03:17:48 --- The save crashes became rare in the new Ubuntu 10.04 Lucid Lynx (KUbuntu), but still happen unexpectedly, approximately after a few tens of saves. I first thought that was because I tried to test wine-1.2-rc1, but then figured out that in older unpatched versions of wine this bug became rare too, so I think this is some influence of the OS upgrade.
The patch from here still seems to work fine. Though now it is difficult to test it with good confidence because the save crashes are pretty rare.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #159 from Roman m01brv@mail.ru 2010-06-10 05:55:11 --- I checked it now more carefully, the patch from here indeed works pretty well. No crashes during 10 days since my last post. With unpatched wine (1.2-rc1, 1.1.40, and 1.1.30) and new Ubuntu these crashes happen approximately one time during each evening (after a few tens of saves in average, but very randomly, sometimes after first few saves). This frequency does not seem to depend on the wine version, but I noted that in wine-1.2-rc1 no usual crash dialog emerge: the game just silently terminates during the saving and no message is reported. Maybe this absence of crash dialogs is due to some other bug or some configuration settings, I am not sure.
Anyway, most of the time during more than a year I run programs using the patched wine, and I have note neither a warcraft save crash no any suspicious behaviour in other apps (at least which would not match other known bugs). Saved games are always loaded normally. This bug is already almost 2.5 years old, and last 1.5 years we have the well-working patch here. It will be quite regretful if this bug migrates in the final wine-1.2! A year ago I even found another app affected by this bug (see my post #142), then why not to fix it?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #160 from John M. Drescher drescherjm@gmail.com 2010-06-10 08:31:59 --- The developers want someone to write a small test application that works on windows but reliably fails in wine to demonstrate this bug. I could do this but I am way too busy at work and I have not messed with IOCP (io completion ports) in over 10 years.
http://bugs.winehq.org/show_bug.cgi?id=11188
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
--- Comment #161 from NSLW lukasz.wojnilowicz@gmail.com 2010-06-19 09:06:13 --- (In reply to comment #160)
The developers want someone to write a small test application that works on windows but reliably fails in wine to demonstrate this bug. I could do this but I am way too busy at work and I have not messed with IOCP (io completion ports) in over 10 years.
Why don't developers write test on their own? Is it too hard or do they think that it's not their business but the creator of the patch?
This bug is highly voted and concerns game that's also highly voted, the fix is already here so I think it's not a bad idea to write test by anyone who know how to do it.
BTW. Fix still works for Wine 1.2-rc4
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #162 from Juan Lang juan_lang@yahoo.com 2010-06-19 11:03:00 --- (In reply to comment #161)
Why don't developers write test on their own? Is it too hard or do they think that it's not their business but the creator of the patch?
This is off topic for fixing the bug, please don't clutter the bug with chatter.
http://bugs.winehq.org/show_bug.cgi?id=11188
enb elitenoobboy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |elitenoobboy@gmail.com
--- Comment #163 from enb elitenoobboy@gmail.com 2010-06-19 11:44:24 --- (In reply to comment #162)
(In reply to comment #161)
Why don't developers write test on their own? Is it too hard or do they think that it's not their business but the creator of the patch?
This is off topic for fixing the bug, please don't clutter the bug with chatter.
No, it is not offtopic. He is asking about why the developers refuse to fix the bug. That line of thought IS ABOUT THE BUG ITSELF, which, correct me if I am wrong here, is the whole reason for having a forum on a bugtracker.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #164 from Reece Dunn msclrhd@gmail.com 2010-06-19 11:56:13 --- (In reply to comment #163)
No, it is not offtopic. He is asking about why the developers refuse to fix the bug. That line of thought IS ABOUT THE BUG ITSELF, which, correct me if I am wrong here, is the whole reason for having a forum on a bugtracker.
The point of the comments is to discuss the problem, devise a solution, propose fixes and comment on them, etc.
Wine developers are working on this on their own free time, and there is a lot of work involved (most requiring domain specific knowledge). For a functional change that implements part of the Windows function calls (like in this case), test cases are required to validate that the behaviour is requested. They also help prevent regressions.
Also, not all Wine developers have access to the program that exhibit the bugs, and may not know enough of the details that trigger the bug, so having a test case can help them understand the issue. Especially since the test case should be repeatable and predictable.
So why is it so hard to ask the people interested in this (or the person who wrote the fix) to write a test case? Especially as they know the most about the issue being fixed.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #165 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-20 00:00:08 --- (In reply to comment #161)
Why don't developers write test on their own? Is it too hard or do they think that it's not their business but the creator of the patch?
A test case serves as a proof that the patch is correct and that the patch creator fully understands what he is doing. Moreover, the test case serves as a measure that there will be no regressions in that area in future. The patch creator should have written some test application in any case to investigate the problem, and writing a test would require someone else to do that work from the very start once again.
This bug is highly voted and concerns game that's also highly voted, the fix is already here so I think it's not a bad idea to write test by anyone who know how to do it.
Without a test case this is just a quick hack. And as has been said many times voting means nothing in the Wine bugzilla.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #166 from Michal Illich list@illich.cz 2010-06-20 02:04:41 --- Let me say also something:
Theoretically, I agree with developers: having a test case would be nice.
But practically: 1. There's a patch for the last 1,5 years. 2. A lot of people confirm that the patch is working. 3. There is noone who reports any issues with the patch. 4. The bug is serious, and both game and bug are highly voted. 5. There is noone willing to write a test case. 6. The crashes are random so it's probably not even possible to write a test case.
Under these circumstances, I think that there's only one options to solve the bug: accept the patch. All the other options are just making excuses - as we all can see they just lead to prolonging the solution and to unhappy users.
http://bugs.winehq.org/show_bug.cgi?id=11188
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #167 from joaopa jeremielapuree@yahoo.fr 2010-06-20 02:13:38 --- Instead of complaining, just take a few minutes of your time to write test cases. Send them to the Wine patches list and then send the fix. It will be more useful than whining.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #168 from Michal Illich list@illich.cz 2010-06-20 02:36:28 --- (In reply to comment #167)
Instead of complaining, just take a few minutes of your time to write test cases. Send them to the Wine patches list and then send the fix. It will be more useful than whining.
Can you explain to us how to write a test case to something that happens randomly?
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #169 from Jason Heeris jason.heeris@gmail.com 2010-06-20 05:53:23 ---
So why is it so hard to ask the people interested in this (or the person who
wrote the fix) to write a test case?
Because you need someone who ticks all the boxes:
1. Encounters this bug with enough frequency to be motivated to help 2. Knows enough about the wine internals to write a test case 3. Has easy access to a copy of Windows to test the other side of things
#2 is sort of optional, since the patch has already been written. #3 is tricky, I know I don't meet it. Anyone who does, AND also meets #1, might just use Windows anyway when they want to play the game, so they don't care as much.
So people who tick #1 get annoyed at the people who tick #2, and no-one likes people in group #3 anyway, and everyone flames everyone else :)
There is noone who reports any issues with the patch.
This could be because the only people who use the patch are listed on this page (maybe not, I don't know).
Can you explain to us how to write a test case to something that happens randomly?
From normal use of WC3, you can get an idea of how frequently the crash occurs.
Then, unless the test case takes a really long time, you run a test case in a loop over a significantly greater number of times than the usual number of attempts it takes to reproduce.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #170 from Juan Lang juan_lang@yahoo.com 2010-06-20 11:43:53 --- (In reply to comment #169)
- Has easy access to a copy of Windows to test the other side of things
Actually, winetestbot addresses this. So only 1. and 2. are needed.
By the way, as far as I can see this was never even submitted to wine-patches. Patches are not picked up from here. While I doubt a change like this would get accepted without a test case, it's impossible for it to get applied without ever having been submitted.
http://bugs.winehq.org/show_bug.cgi?id=11188
luke16 luke16@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|luke16@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #171 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-21 02:34:03 --- (In reply to comment #168)
Can you explain to us how to write a test case to something that happens randomly?
The creator of the patch somehow figured the problem out. That's not realistic to ask someone else to that once again from the start. Noone would ask for a test case if it would be that simple. Creating a test case sometimes needs much more experience and knowledge than creating a quick hack which appears to work for single type of an application.
http://bugs.winehq.org/show_bug.cgi?id=11188
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #172 from Austin English austinenglish@gmail.com 2010-06-21 11:14:32 --- Should be fixed by http://source.winehq.org/git/wine.git/?a=commitdiff;h=5b3750e2a4496c6088af82....
Thanks Andrey!
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #173 from NSLW lukasz.wojnilowicz@gmail.com 2010-06-21 11:25:54 --- I also want to say thank you.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #174 from Andrey Turkin andrey.turkin@gmail.com 2010-06-21 11:30:25 --- Well, hopefully this bug won't see 200-th comment. My apologies to everyone for this 1.5 years lag between proof-of-concept patch and in-tree fix :)
About test case - it is impossible to write 100% reliable test case for this bug; also test case isn't needed as the bug cause is obvious.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #175 from Claudio sick_soul@yahoo.it 2010-06-21 13:44:56 --- (In reply to comment #174)
Well, hopefully this bug won't see 200-th comment. My apologies to everyone for this 1.5 years lag between proof-of-concept patch and in-tree fix :)
About test case - it is impossible to write 100% reliable test case for this bug; also test case isn't needed as the bug cause is obvious.
it might only get closer to 200 with the "thank you"s..
From an user perspective, which I have with wine, having an in-tree fix gives a
perception of improvement to the codebase, that makes me hope for wine's future as a technology.
Whenever a regression is present, even in something I do not use, it hurts.
So thank you (but I'll test :))
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #176 from Louigi Verona louigi.verona@gmail.com 2010-06-21 14:12:46 --- Wow! Sounds like super great news! Thank you thank you thank you! But when exactly will this fix be applied? And how to make it work here? As seen from my comments above, I could not patch my WINE - it failed at the first step, so to this day I cannot play Warcraft III.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #177 from NSLW lukasz.wojnilowicz@gmail.com 2010-06-21 14:30:29 --- (In reply to comment #176)
Please wait till Wine-1.2-rc5 release. The patch is already applied in today's git.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #178 from enb elitenoobboy@gmail.com 2010-06-21 14:32:59 --- (In reply to comment #176)
seen from my comments above, I could not patch my WINE - it failed at the first step, so to this day I cannot play Warcraft III.
If patching it didn't work, you could have grabbed the pre-patched wine from repo.or.cz as mentioned on the warcraft abbdb page.
Anyways, thanks for including the patch, even if a few years late. :)
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #179 from Louigi Verona louigi.verona@gmail.com 2010-06-21 14:36:25 --- Yeah, well actually it is the grabbing that failed. On the first step - the git simply did not respond.
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #180 from Michal Illich list@illich.cz 2010-06-21 14:53:26 --- Hooray! And thanks!
http://bugs.winehq.org/show_bug.cgi?id=11188
Martin Jürgens martin@gamesplace.info changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|martin@gamesplace.info |
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #181 from Roman m01brv@mail.ru 2010-06-22 06:23:31 --- Eventually! I am happy hearing that! I spent last evening in an attempt to reproduce this bug in a test IOCP app (unsuccessfully), and now really glad that the bug goes away.
Many many many thanks!
http://bugs.winehq.org/show_bug.cgi?id=11188
--- Comment #182 from Louis louis@qdcec.co.za 2010-06-23 07:57:40 --- As the original logger of the fault ... MANY thanks to all who took part in fixing this.
http://bugs.winehq.org/show_bug.cgi?id=11188
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #183 from Alexandre Julliard julliard@winehq.org 2010-06-25 12:40:26 --- Closing bugs fixed in 1.2-rc5.
-
wine-bugs＠winehq.org