http://bugs.winehq.org/show_bug.cgi?id=11788
Summary: Icewind Dale crashes when starting Product: Wine Version: CVS/GIT Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs@winehq.org ReportedBy: ns03ja@brocku.ca CC: julliard@winehq.org
Created an attachment (id=11050) --> (http://bugs.winehq.org/attachment.cgi?id=11050) Crash log
As of quite recently, Icewind Dale now crashes when attempting to run it. A regression test reveals:
1642fbcbc2b4133cf0ce29c3539082cc1027180b is first bad commit commit 1642fbcbc2b4133cf0ce29c3539082cc1027180b Author: Alexandre Julliard julliard@winehq.org Date: Mon Feb 25 15:59:19 2008 +0100
user32: Moved the DCE support from winex11 back to user32.
Window and class DCEs are now allocated lazily.
:040000 040000 065d0761485210c3b8cd9c971ec24e993c8cce09 b5689374b7880b78c75cd32732ac5010b99fe52a M dlls :040000 040000 aff755513bfcd611b96ae7dade200dcdd42c764f 9e19e743cdcda8d42eaa78b4ded736459cc763cc M include
Before the above commit, Icewind Dale ran flawlessly.
Unfortunately, I don't know of any Icewind Dale demo.
See the attached log.
http://bugs.winehq.org/show_bug.cgi?id=11788
Neil Skrypuch ns03ja@brocku.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2008-03-04 04:57:10 --- Please attach a WINEDEBUG=relay,win,seh trace.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #2 from Neil Skrypuch ns03ja@brocku.ca 2008-03-05 02:53:57 --- Created an attachment (id=11119) --> (http://bugs.winehq.org/attachment.cgi?id=11119) WINEDEBUG=relay,win,seh log, no crash
(In reply to comment #1)
Please attach a WINEDEBUG=relay,win,seh trace.
Here's the (bzipped) log, however, Icewind Dale doesn't crash when run with that particular WINEDEBUG, so I'm not sure how useful it will be...
Since there's no crash in this case, I just started Icewind Dale and then immediately quit using the main menu to produce the log.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2008-03-05 03:14:18 --- I'm afraid the log is useless if it doesn't show the crash. Maybe try without relay first.
http://bugs.winehq.org/show_bug.cgi?id=11788
Neil Skrypuch ns03ja@brocku.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #11119|0 |1 is obsolete| |
--- Comment #4 from Neil Skrypuch ns03ja@brocku.ca 2008-03-05 03:34:03 --- Created an attachment (id=11120) --> (http://bugs.winehq.org/attachment.cgi?id=11120) WINEDEBUG=win,seh crash log
Ok, here's the crash log with just win and seh channels.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2008-03-05 04:44:42 --- There doesn't seem to be any windowing calls before the crash, this looks more like a dsound bug triggered by some timing difference. You could try a +dsound trace, but it looks like you'll have to debug this yourself; try to figure out where the bad pointer comes from, it looks like a vtable address gone bad.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #6 from Neil Skrypuch ns03ja@brocku.ca 2008-03-05 15:43:54 --- Well, it doesn't seem like a dsound bug, adding dsound to the trace only added 4 lines before the crash:
trace:dsound:DllMain (0x7e580000 8 (nil)) trace:dsound:DllMain UNKNOWN REASON (...) trace:dsound:DllMain (0x7e580000 1 0x1) trace:dsound:DllMain DLL_PROCESS_ATTACH
http://bugs.winehq.org/show_bug.cgi?id=11788
Alexander Dorofeyev alexd4@inbox.lv changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexd4@inbox.lv
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #7 from Alexander Dorofeyev alexd4@inbox.lv 2008-03-21 20:00:11 --- For me the result of regression test is different.
220163ee9d698543fe34257969a88e5976d378de is first bad commit commit 220163ee9d698543fe34257969a88e5976d378de Author: Roderick Colenbrander thunderbird2k@gmx.net Date: Fri Feb 22 20:55:02 2008 +0000
wgl: Remove unneeded opengl initialisation code at wine startup.
FWIW reverting this commit indeed produces a working version, crash goes away. Very strange.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #8 from Alexander Dorofeyev alexd4@inbox.lv 2008-03-22 08:23:51 --- I tried debugging this in IDA disassembler. It looks like the wrong pointer accessed is a field of some very large struct or object allocated on the stack. It's allocated on the stack in WinMain, then passed to a chain of subroutines. Now, the strange part is, it looks like this particular field isn't really properly initialized by the app, and this causes problems. There's a check later on if it's NULL or not, but it isn't really initialized to NULL anywhere as far as I can see, it looks like this variable ends up with some semi-random value from the stack. This can explain inconsistency with regression tests. If value at that address happens to be 0, then everything if fine, otherwise the app tries to use this wrong value as a pointer later and crashes. This is totally dependent on what is in stack upon entering WinMain - by putting some value at that address I can cause crash by accessing this value (as pointer) or avoid the crash if I put 0x00000000 there.
So this really looks like a buggy app, but somehow it works on Windows. Maybe stack memory is zeroed in Windows, but not in Wine, I don't know. Possibly some exe-loading issue.
2 Alexandre Julliard: do you know if above theory can be correct?
This important address that decides whether app will run or crash is ESP-0x4E02, when at the very first instruction of WinMain. I don't know much about exe loading but I can try to dig some more info on request.
I'll also try to check on Windows, how the stack looks there, zeroed or not.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #9 from Alexander Dorofeyev alexd4@inbox.lv 2008-03-23 10:57:20 --- Ok i tried this on windows. There, on entering WinMain, the address in question is on a page not yet accessible. The first thing WinMain does is passes 0x51DC (apparently size of object it allocated on the stack) to some routine that fetches a byte from every page so this area is added to stack and seems to be initialized to zeros. That's probably why on Windows it doesn't fail this way, because the pointer at [esp-0x4e02] thus gets initialized to NULL.
I don't know what's the right way to do about this on Wine (if any) - maybe juts zero-fill the stack on startup before passing control to the app.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2008-03-25 14:17:53 --- Nice analysis, your theory sounds quite plausible. Probably our dll initializations use more stack than their Windows counterpart. Could you please get a +loaddll trace to show which dlls the app loads?
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #11 from Alexander Dorofeyev alexd4@inbox.lv 2008-03-25 15:04:20 --- Created an attachment (id=11642) --> (http://bugs.winehq.org/attachment.cgi?id=11642) +loaddll log
Here, log with +loaddll.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #12 from Alexandre Julliard julliard@winehq.org 2008-03-25 17:23:21 --- Thanks. It looks like the main offender is the CUPS library called from winspool.drv init, not sure there's a lot we can do to avoid that. We probably have to clear the stack explicitly after the dll init is done.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2008-03-27 07:32:56 --- I committed a fix to clear the stack after dll init, please test if it works for you.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #14 from Alexander Dorofeyev alexd4@inbox.lv 2008-03-27 13:01:00 --- Alexandre Julliard: it works for me with current git, thanks for fixing.
http://bugs.winehq.org/show_bug.cgi?id=11788
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2008-03-27 16:08:15 --- Fixed.
http://bugs.winehq.org/show_bug.cgi?id=11788
Neil Skrypuch ns03ja@brocku.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|FIXED |
--- Comment #16 from Neil Skrypuch ns03ja@brocku.ca 2008-03-27 22:06:13 --- I just got a chance to test this now, and unfortunately the mentioned patch does not help. I'll have a closer look at this with IDA in a few days.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #17 from Alexander Dorofeyev alexd4@inbox.lv 2008-03-28 06:59:58 --- Damn. Hard to believe there can be two simultaneous regressions. Neil, are you sure you are doing everything right? Maybe try with a new .wine dir? And what version do you have, did you apply the latest patch?
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #18 from Alexander Dorofeyev alexd4@inbox.lv 2008-03-28 07:01:05 --- Correction: by version I meant Icewind Dale patch version (in the previous post).
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #19 from Neil Skrypuch ns03ja@brocku.ca 2008-03-28 13:24:23 --- I'm using Icewind Dale with the expansion pack (Heart of Winter) installed. The "Options" dialog in game reports v1.4 (021002).
IIRC, there's only one version possible with the expansion pack installed, as it includes all of the previous patches for the original game.
I could try in a new WINEPREFIX, but currently I have Icewind Dale in it's own prefix with nothing else installed in there. I'm also running a (tiny) script to run Icewind Dale, so it's the same every time:
#!/bin/bash
cd ~/.wine-iwd1/drive_c/Program\ Files/Black\ Isle/Icewind\ Dale/ export WINEPREFIX=~/.wine-iwd1 xinit ~/wine-git/wine IDMain.exe -- :1
Running it in the current X server (rather than a new one) didn't change anything before.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #20 from Alexander Dorofeyev alexd4@inbox.lv 2008-03-29 07:29:49 --- Neil, I'm able to install, start, create characters and run game in Heart of Winter with latest git. The concern about wine prefix isn't that you may have something else installed, it has more to do with this: prefix reuse in different wine versions sometimes causes strange problems. I just had one of those when trying to install HoW (it wouldn't install until i tried with fresh wine prefix). Also new prefix guarantees you get all default settings. Of course, I can't tell whether this is what causes your problem or not, but to be sure please try to reinstall everything into newly created wine prefix and retest.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #21 from Neil Skrypuch ns03ja@brocku.ca 2008-04-09 04:44:33 --- Ok, so I finally found time to try with a fresh WINEPREFIX and the result is the same for me, Icewind Dale (with Heart of Winter) still crashes upon startup.
However, plain old Icewind Dale (without Heart of Winter) does *not* crash while starting, and indeed it appears to work just fine, although I didn't go beyond the main menu.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #22 from Alexander Dorofeyev alexd4@inbox.lv 2008-04-12 09:20:51 --- (In reply to comment #21)
Ok, so I finally found time to try with a fresh WINEPREFIX and the result is the same for me, Icewind Dale (with Heart of Winter) still crashes upon startup.
However, plain old Icewind Dale (without Heart of Winter) does *not* crash while starting, and indeed it appears to work just fine, although I didn't go beyond the main menu.
Neil: I analyzed your Heart of Winter crash backtrace in IDA (first and third attachments), and while addresses are slightly different from Icewind Dale 1.06 backtraces I was getting, the problem appears similar in origin (it's an address allocated on the stack that should be 0, and looks like a direct sound interface reference). I don't know why this problem still appears for you even though it should be fixed (and is indeed fixed for me). Are you sure git is totally up-to-date?
Anyway, if you are absolutely sure you are not using older wine version, post a crash log for the current version please. Maybe it's crashing now because of some other problem, who knows.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #23 from Neil Skrypuch ns03ja@brocku.ca 2008-04-12 21:59:07 --- Created an attachment (id=12112) --> (http://bugs.winehq.org/attachment.cgi?id=12112) Crash log with 0.9.59
I just tested this on current git, and the crash is gone! I bisected this and found that the following patch fixes (or hides) the bug:
185157cb6eb25bc5e75e9a260b593e98153d2255 is first bad commit commit 185157cb6eb25bc5e75e9a260b593e98153d2255 Author: Kusanagi Kouichi slash@ma.neweb.ne.jp Date: Fri Apr 4 20:44:36 2008 +0900
winex11: Connect to XIM server dynamically.
:040000 040000 4df81736d311abdd4b603e64987fb90e4e5c9a71 7999fe03f030755e4e731116a1701b0779e07ab7 M dlls
I also tested 0.9.59, which does suffer from the crash.
Also, this does appear to be a timing sensitive bug, perhaps it would be useful to know what kind of system I'm running:
64-bit Gentoo Athlon X2 4200+ (2x 2.2 Ghz) 2G RAM (normally, currently 1G) Geforce 7950 GT Soundblaster Live! (the original, using snd_emu10k1) GCC 4.1.2 Linux x2-42 2.6.24-gentoo-r2 #1 SMP PREEMPT Mon Feb 11 03:53:34 EST 2008 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux
Actually, I'm now reminded of bug 4047, which seems related...
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #24 from Alexander Dorofeyev alexd4@inbox.lv 2008-04-13 07:18:21 --- (In reply to comment #23)
Created an attachment (id=12112)
--> (http://bugs.winehq.org/attachment.cgi?id=12112) [details]
Crash log with 0.9.59
I just tested this on current git, and the crash is gone! I bisected this and found that the following patch fixes (or hides) the bug:
185157cb6eb25bc5e75e9a260b593e98153d2255 is first bad commit commit 185157cb6eb25bc5e75e9a260b593e98153d2255 Author: Kusanagi Kouichi slash@ma.neweb.ne.jp Date: Fri Apr 4 20:44:36 2008 +0900
winex11: Connect to XIM server dynamically.
That isn't too good. If unrelated commit "fixed" it, it's possible the actual bug just became hidden as it was before, and may reappear later. The problem is sensetive to what code executes before and what it leaves in memory, so even small changes to init code or some routines in wine's dlls etc can hide the problem.
I checked your log - it's apparently the same spot in the program again, so it seems the same problem is still there.
In the Heart Of Winter, the interesting address which decides whether program gets to the problem code or not, is slightly different than in original Icewind Dale: ESP-0x4A9E upon entering WinMain.
Would be interesting to find out why that address is not-zeroed on your machine. Were you successful at getting it to run in IDA? I could provide you some help and guidance if you need it, with running Icewind/HOF in IDA in Wine. If interested, try to find me in irc, #winehackers, my screen name there is frostbite4.
So far I've found that between WinMain and initial entry point ("start") there are some routines called that use quite a lot of stack. At some point there's a GetDC call, that (on my machine) appears to change stack as far as at least 2 memory pages below ESP (as seen at the beginning of WinMain or at 'start' entry point). Perhaps, under certain circumstances, this GetDC call can "pollute" stack up to and including the address which, if non-zeroed, leads to Icewind/HOF crashing.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #25 from Alexander Dorofeyev alexd4@inbox.lv 2008-04-13 12:00:02 --- Created an attachment (id=12131) --> (http://bugs.winehq.org/attachment.cgi?id=12131) binary patch of IDMain.exe to fix wrong ptr access (xdelta)
As a workaround, I patched a few instructions in Icewind Dale HofW IDMain.exe and generated a binary patch using the xdelta utility. Perhaps this can help.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #26 from Alexander Dorofeyev alexd4@inbox.lv 2008-04-13 12:13:11 --- Created an attachment (id=12132) --> (http://bugs.winehq.org/attachment.cgi?id=12132) Patch of origin IWD (no expansion) IDMain.exe to fix wrong ptr access (xdelta)
Just in case it will start occuring in original IWD, here's similar patch to it (appears to work just the same with initial retail exe and patched 1.06 exe).
http://bugs.winehq.org/show_bug.cgi?id=11788
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #27 from Vitaliy Margolen vitaliy@kievinfo.com 2008-06-08 13:18:36 --- (In reply to comment #23)
Created an attachment (id=12112)
--> (http://bugs.winehq.org/attachment.cgi?id=12112) [details]
Crash log with 0.9.59
I just tested this on current git, and the crash is gone! I bisected this and found that the following patch fixes (or hides) the bug:
185157cb6eb25bc5e75e9a260b593e98153d2255 is first bad commit commit 185157cb6eb25bc5e75e9a260b593e98153d2255 Author: Kusanagi Kouichi slash@ma.neweb.ne.jp Date: Fri Apr 4 20:44:36 2008 +0900
winex11: Connect to XIM server dynamically.:040000 040000 4df81736d311abdd4b603e64987fb90e4e5c9a71 7999fe03f030755e4e731116a1701b0779e07ab7 M dlls
Please see bug 13143 for possible solution.
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #28 from Neil Skrypuch ns03ja@brocku.ca 2008-07-12 12:53:17 --- Git from about a month ago didn't work with -O2, but was fine with -O0. Unfortunately I don't remember exactly what version that was. Wine 1.1.1 seems fine either way, though.
Setting UseXIM to Y or N as suggested in bug 13143 didn't seem to have any effect.
http://bugs.winehq.org/show_bug.cgi?id=11788
vegandalf vegandalf@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vegandalf@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11788
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
--- Comment #29 from Austin English austinenglish@gmail.com 2009-01-18 03:48:00 --- Removing deprecated CVS/GIT version tag. Please retest in current git. If the bug is still present in today's wine, but was not present in some earlier version of wine, please update version field to earliest known version of wine that had the bug. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=11788
--- Comment #30 from Austin English austinenglish@gmail.com 2009-07-21 13:50:02 --- Is this still an issue in current (1.1.26 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=11788
Lauri Kenttä lauri.kentta@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lauri.kentta@gmail.com
--- Comment #31 from Lauri Kenttä lauri.kentta@gmail.com 2009-10-25 05:55:42 --- Works for me with a clean wineprefix, using IWD HoW version 1.42, 062714 (Trials of the Luremaster).
I only get a crash from Intel graphics driver (i965_dri.so), which can be fixed with using registry key Direct3D/OffscreenRenderingMode = "pbuffer". This is probably a bug in Mesa.
http://bugs.winehq.org/show_bug.cgi?id=11788
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #32 from Jeff Zaroyko jeffz@jeffz.name 2010-01-07 07:10:37 --- (In reply to comment #31)
Works for me with a clean wineprefix, using IWD HoW version 1.42, 062714 (Trials of the Luremaster).
Reported fixed.
http://bugs.winehq.org/show_bug.cgi?id=11788
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |0.9.54.
http://bugs.winehq.org/show_bug.cgi?id=11788
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #33 from Jeff Zaroyko jeffz@jeffz.name 2010-01-09 04:53:25 --- Closing bugs fixed in 1.1.36.
-
wine-bugs＠winehq.org