http://bugs.winehq.org/show_bug.cgi?id=18040
Summary: Mass Efffect GPF Regression. 1.1.19 Product: Wine Version: 1.1.19 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P5 Component: msvcrt AssignedTo: wine-bugs@winehq.org ReportedBy: chadwick@clan-mac.com
So I tried this with the binary from Scott Ritchie for ubuntu 1.1.19 and Mass Effect Pops up this GPF window.
I have a backtrace I'll post now too.
If you give me commands to run I'll run them.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #1 from Chadwick Ferguson chadwick@clan-mac.com 2009-04-14 00:37:05 --- Created an attachment (id=20432) --> (http://bugs.winehq.org/attachment.cgi?id=20432) Tracelog
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #2 from Chadwick Ferguson chadwick@clan-mac.com 2009-04-14 00:37:47 --- Created an attachment (id=20433) --> (http://bugs.winehq.org/attachment.cgi?id=20433) Screenshot
http://bugs.winehq.org/show_bug.cgi?id=18040
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #20432|application/x-ms-dos- |text/plain mime type|executable | Attachment #20432|wine masseffect.exe |output.txt filename| |
http://bugs.winehq.org/show_bug.cgi?id=18040
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|msvcrt |-unknown Keywords| |regression Summary|Mass Efffect GPF Regression.|Mass Efffect crashes |1.1.19 |
--- Comment #3 from Jeff Zaroyko jeffz@jeffz.name 2009-04-14 00:40:33 ---
From the new bug reporting page: "run a regression test before submitting a bug
report about a regression" http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=18040
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 |P2
http://bugs.winehq.org/show_bug.cgi?id=18040
Marcin ergo14@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ergo14@gmail.com
--- Comment #4 from Marcin ergo14@gmail.com 2009-04-14 07:14:50 --- latest commits i think it were d3d commits made on 2009-04-10 introduced this bug, i remember i compiled trunk from source on 2009-04-08(wednesday) or 2009-04-09(thursday) and by then mass effect was still functioning fine. it broke for me when i compiled tagged 1.1.19 on friday evening.
hope that helps
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #5 from Austin English austinenglish@gmail.com 2009-04-14 11:04:54 --- (In reply to comment #4)
latest commits i think it were d3d commits made on 2009-04-10 introduced this bug, i remember i compiled trunk from source on 2009-04-08(wednesday) or 2009-04-09(thursday) and by then mass effect was still functioning fine. it broke for me when i compiled tagged 1.1.19 on friday evening.
hope that helps
We need the specific commit.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #6 from Marcin ergo14@gmail.com 2009-04-14 11:10:27 --- ok, ill run a bisect, should get back with results today ;-)
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #7 from Marcin ergo14@gmail.com 2009-04-14 13:37:49 --- ergo@ergo:~/source/wine$ git bisect bad 014c4bfc70a4d4e60f033d579d1be13a46f65170 is first bad commit commit 014c4bfc70a4d4e60f033d579d1be13a46f65170 Author: Stefan Dösinger stefan@codeweavers.com Date: Thu Apr 9 18:40:57 2009 +0200
wined3d: Save some memory in vertex buffers.
In most cases we're fine with the vbo and glMapBuffer and never use the actual heap memory copy. Try to stick to just the vbo copy and avoid allocating the extra heap memory. In case it is needed(emulation or vertex conversion), fall back to the old double buffering mode.
:040000 040000 e45dcc2b8694735b0a68492a7a03237b1c519ae3 0447d35c1e1a2037a962b49802a03a9dad1bf59e M dlls
ok i was running regression test first time in my life so i hope i didnt mess anything
just testing with : git bisect start dlls/wined3d
and ended up with that specific commit, if i didnt mess up anything its this one or previous one to wined3d ;-) im 95% sure its this one.
is that helpful and specific enough :-) ?
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #8 from Austin English austinenglish@gmail.com 2009-04-14 14:00:33 --- (In reply to comment #7)
ergo@ergo:~/source/wine$ git bisect bad 014c4bfc70a4d4e60f033d579d1be13a46f65170 is first bad commit commit 014c4bfc70a4d4e60f033d579d1be13a46f65170 Author: Stefan Dösinger stefan@codeweavers.com Date: Thu Apr 9 18:40:57 2009 +0200
wined3d: Save some memory in vertex buffers. In most cases we're fine with the vbo and glMapBuffer and never use theactual heap memory copy. Try to stick to just the vbo copy and avoid allocating the extra heap memory. In case it is needed(emulation or vertex conversion), fall back to the old double buffering mode.
:040000 040000 e45dcc2b8694735b0a68492a7a03237b1c519ae3 0447d35c1e1a2037a962b49802a03a9dad1bf59e M dlls
ok i was running regression test first time in my life so i hope i didnt mess anything
just testing with : git bisect start dlls/wined3d
and ended up with that specific commit, if i didnt mess up anything its this one or previous one to wined3d ;-) im 95% sure its this one.
is that helpful and specific enough :-) ?
That looks right. To be sure, try: $ git reset --hard 014c4bfc70a4d4e60f033d579d1be13a46f65170 $ ./configure && make depend && make
Should fail.
Then try: $ git show 014c4bfc70a4d4e60f033d579d1be13a46f65170 | patch -p1 -R $ ./configure && make depend && make
and retest. If it works, then that's definitely the patch.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #9 from Marcin ergo14@gmail.com 2009-04-14 14:28:02 --- YAY!!! correct :-)
my first correctly found regression :P
keep up great work guys.
Unreal engine 3 games are now playable more or less :]
http://bugs.winehq.org/show_bug.cgi?id=18040
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #10 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-14 15:22:05 --- Can you attach a +d3d log? Maybe I can spot something in there.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #11 from Marcin ergo14@gmail.com 2009-04-14 15:45:34 --- how do i do that ? ;-)
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #12 from Austin English austinenglish@gmail.com 2009-04-14 21:25:41 --- (In reply to comment #11)
how do i do that ? ;-)
WINEDEBUG=+d3d wine your_app.exe &> /tmp/d3d.txt
then attach /tmp/d3d.txt here.
http://bugs.winehq.org/show_bug.cgi?id=18040
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dhess31@comcast.net
--- Comment #13 from Austin English austinenglish@gmail.com 2009-04-14 21:30:06 --- *** Bug 18035 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=18040
DL taedium_vitae@eml.cc changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #14 from DL taedium_vitae@eml.cc 2009-04-16 21:21:08 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #15 from Marcin ergo14@gmail.com 2009-04-18 06:49:11 --- ok im attaching a full d3d log from crash made on trunk build:
commit 781b0873e60a39c3c604ae17212c8242ff0b856e Author: Jacek Caban jacek@codeweavers.com Date: Wed Apr 15 19:58:05 2009 +0200
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #16 from Marcin ergo14@gmail.com 2009-04-18 06:49:57 --- Created an attachment (id=20524) --> (http://bugs.winehq.org/attachment.cgi?id=20524) d3d log
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #17 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-18 07:35:27 --- Thanks for the log.
winedbg parses the wined3d debug symbols, which suggests that the crash occurs inside wined3d or the opengl driver. However, the backtrace is not very conclusive:
Backtrace: =>0 0x023cf9e0 (0x0052d07c) 1 0x10d94b16 in masseffect (+0x494b16) (0x0052d0a0) 2 0x10db2f40 in masseffect (+0x4b2f40) (0x0052fcd8) 3 0x00000000 (0x00000000)
Can you see if the game writes a minidump file or something similar? I suspect the backtrace we see here is from a follow-up exception, not the original issue.
The D3D log up to the crash doesn't ring any bells so far. Can you add +d3d_draw,+d3d9 to the log?
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #18 from Chadwick Ferguson chadwick@clan-mac.com 2009-04-18 08:37:10 --- Created an attachment (id=20526) --> (http://bugs.winehq.org/attachment.cgi?id=20526) +d3d,+d3d9,+d3d_draw
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #19 from Chadwick Ferguson chadwick@clan-mac.com 2009-04-18 08:39:07 --- Created an attachment (id=20527) --> (http://bugs.winehq.org/attachment.cgi?id=20527) dump generated by windows executeable
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #20 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 05:53:10 --- Unfortunately the new log doesn't contain any extra information, and the minidump fails to load for me(in winedbg). The wined3d debug info loading is gone from the log though. The crash comes from a jump to an invalid address, so maybe in the past log the address was by chance in an area occupied by wined3d.
Mass Effect seems to be an MMORPG game, right? Is there a way to reproduce the bug without having an account? It would be easier for me if I had this game on my hard disk instead of remote debugging via Bugzilla :-/
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #21 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 05:59:28 --- There's one more thing you can try. Can you modify IWineD3DDeviceImpl_CreateIndexBuffer in dlls/wined3d/device.c this way:
right before the "return WINED3D_OK;" (aroud line 582), insert "object->flags |= WINED3D_BUFFER_DOUBLEBUFFER;" This will essentially disable the new memory saving feature with the least code modification and give some hint where things are going wrong.
I have the horrible suspicion that the game tries to access the buffer memory after calling Unlock(). This is invalid, but happened to work with the old code, but depends on the OpenGL driver's mercy in the new code. If this is the case, we'll have to revert the memsave patch :-(
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #22 from Marcin ergo14@gmail.com 2009-04-19 08:10:09 --- mass effect is not a mmo game, you can easly get it on your disk, but its big download ;-)
ill check your last advice in a moment!
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #23 from Marcin ergo14@gmail.com 2009-04-19 08:26:13 --- yup, unfortunately adding the line you mentioned allowed the game to start fine :(
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #24 from Don Hess dhess31@comcast.net 2009-04-19 09:44:39 --- (In reply to comment #23)
yup, unfortunately adding the line you mentioned allowed the game to start fine :(
This fix also allows EQ2 to work again as well.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #25 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 10:47:17 --- I'm currently downloading the EverQuest 2 demo. This demo is reasonably small with 18 mb. I'll see what I can find.
It's not yet said that this is a game bug like I guessed in my last post. I could have missed a buffer memory access in my patch. It would certainly suck if we have to keep lots of useless memory around to please broken apps.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #26 from Marcin ergo14@gmail.com 2009-04-19 10:52:10 --- i dont want to make any statements i cant proove, byt mass effect uses one of the best game engines currently available (unreal engine 3), making that work well will indicate that probably one of the most advanced engines out there works well, games like bioshock ( it has a demo), gears of war etc. use that engine, cant say how bioshock behaves as i didnt tried it, but its worth to check of someone has time.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #27 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 13:22:38 --- Bad stuff: I couldn't find a Mass Effect demo, and so far I haven't managed to get an EverQuest 2 demo account. That means that so far I have not been able to reproduce the bug myself :-(
One more attempts with the logs: Can you make a d3d,d3d_draw,d3d_surface,d3d9,seh with Mass Effect, and (for Don), the same log with EverQuest?
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #28 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 13:35:52 --- Created an attachment (id=20554) --> (http://bugs.winehq.org/attachment.cgi?id=20554) A fix for buffer_get_sysmem
I had a quick look at the code and saw something I didn't quite like. Can you give this patch a try? Please remove the modification in device.c when testing it, otherwise the patch won't make a difference.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #29 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 13:44:35 --- Created an attachment (id=20555) --> (http://bugs.winehq.org/attachment.cgi?id=20555) Two more direct buffer accesses
This is another patch, it is independent of the first one. It fixes two more cases where code accesses buffer->resource.allocatedMemory directly. Please give it a try.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #30 from Chadwick Ferguson chadwick@clan-mac.com 2009-04-19 13:49:10 --- Created an attachment (id=20556) --> (http://bugs.winehq.org/attachment.cgi?id=20556) d3d,d3d_draw,d3d_surface,d3d9,seh
d3d,d3d_draw,d3d_surface,d3d9,seh
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #31 from Chadwick Ferguson chadwick@clan-mac.com 2009-04-19 13:52:24 --- (In reply to comment #30)
Created an attachment (id=20556)
--> (http://bugs.winehq.org/attachment.cgi?id=20556) [details]
d3d,d3d_draw,d3d_surface,d3d9,seh
d3d,d3d_draw,d3d_surface,d3d9,seh
this is with the first patch
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #32 from Chadwick Ferguson chadwick@clan-mac.com 2009-04-19 14:02:04 --- (In reply to comment #29)
Created an attachment (id=20555)
--> (http://bugs.winehq.org/attachment.cgi?id=20555) [details]
Two more direct buffer accesses
This is another patch, it is independent of the first one. It fixes two more cases where code accesses buffer->resource.allocatedMemory directly. Please give it a try.
I can get into the game now.... gameplay looks good. once these patches are committed should be resolved fixed.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #33 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 14:18:52 --- So the 2nd patch fixes Mass Effect? That's certainly a promising sign.
Now we have to know if it helps EQ2 as well. I just got a report on #winehackers that the regression affects Crysis as well, but isn't fixed by the two patches.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #34 from Don Hess dhess31@comcast.net 2009-04-19 14:26:07 --- (In reply to comment #33)
So the 2nd patch fixes Mass Effect? That's certainly a promising sign.
Now we have to know if it helps EQ2 as well. I just got a report on #winehackers that the regression affects Crysis as well, but isn't fixed by the two patches.
The patches did NOT fix EQ2 either. It still crashes trying to enter the character loading/creation screen.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #35 from Don Hess dhess31@comcast.net 2009-04-19 16:19:34 --- (In reply to comment #34)
(In reply to comment #33)
So the 2nd patch fixes Mass Effect? That's certainly a promising sign.
Now we have to know if it helps EQ2 as well. I just got a report on #winehackers that the regression affects Crysis as well, but isn't fixed by the two patches.
The patches did NOT fix EQ2 either. It still crashes trying to enter the character loading/creation screen.
BTW, those patches killed some other games that work with stock 1.1.19 like WOW. After about 5 minutes, Wow started to stutter then crashed. I had to revert back to the original 1.1.19.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #36 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 16:25:07 --- I start to think that the Crysis issue is a memory corruption that was triggered by the patch. Still debugging.
Don, I'll attach another test and debug patch. Can you see if it fixes the game, and if not, make a d3d,d3d_draw,d3d_surface,d3d9,seh,tid log? (The list of channels is getting long - tid gives threading information)
BTW, those patches killed some other games that work with stock 1.1.19 like WOW. After about 5 minutes, Wow started to stutter then crashed. I had to revert back to the original 1.1.19.
Not that's strange, I don't see how they could do that. Are you sure that there aren't some other changes interfering?
On the bright side I have WoW here, so I can test that myself if needed.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #37 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 16:27:05 --- Created an attachment (id=20559) --> (http://bugs.winehq.org/attachment.cgi?id=20559) Another test patch
Applies on top of "A fix for buffer_get_sysmem" and "Two more direct buffer accesses"
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #38 from Don Hess dhess31@comcast.net 2009-04-19 17:22:06 --- (In reply to comment #37)
Created an attachment (id=20559)
--> (http://bugs.winehq.org/attachment.cgi?id=20559) [details]
Another test patch
Applies on top of "A fix for buffer_get_sysmem" and "Two more direct buffer accesses"
Didn't fix it either. I'll attach a log.
OK. I won't attach a log, it's too big 3.8 meg compressed, 80+ uncompressed
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #39 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-19 19:19:46 --- Don, 3.8MB sounds a bit big for a log that is 80 MB uncompressed. Did you try bzip2 -9 ? Some other compression tools might get better results, like 7zip or lrzip. lrzip was specially designed for logfiles, so it should make the file reasonably small here.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #40 from Don Hess dhess31@comcast.net 2009-04-19 20:40:12 --- Created an attachment (id=20564) --> (http://bugs.winehq.org/attachment.cgi?id=20564) EQ2 crash log. This is the log with the patches
This is the log with the patches from the bug report for EQ2.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #41 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-20 06:09:15 --- Don, this log is very helpful. It seems that the game crashes in buffer_Map() in dlls/wined3d/buffer.c. The crash occurs somewhere between the first trace and the trace at the end. Can you add some more traces to the code to find out which path it takes and where it crashes? The glMapBufferARB() call is suspicious. Maybe it returns NULL(although that should not crash in this function, maybe later). Maybe it crashes inside the GL code.
http://bugs.winehq.org/show_bug.cgi?id=18040
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #20559|0 |1 is obsolete| |
--- Comment #42 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-20 06:29:04 --- Created an attachment (id=20570) --> (http://bugs.winehq.org/attachment.cgi?id=20570) Threading fix for buffer maps
Hi Don, Here's another patch to try. I realized that EQ2 calls the crashing buffer_map() call from a different thread, and the new GL calls do not have an ActivateContext call to deal with multithreading, and they did not have the ENTER_GL() locking calls. This patch fixes that.
Please apply it on top of the two patches that fixed Mass Effect, but without the "another test patch" debug patch.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #43 from Don Hess dhess31@comcast.net 2009-04-20 18:14:20 --- (In reply to comment #42)
Created an attachment (id=20570)
--> (http://bugs.winehq.org/attachment.cgi?id=20570) [details]
Threading fix for buffer maps
Hi Don, Here's another patch to try. I realized that EQ2 calls the crashing buffer_map() call from a different thread, and the new GL calls do not have an ActivateContext call to deal with multithreading, and they did not have the ENTER_GL() locking calls. This patch fixes that.
Please apply it on top of the two patches that fixed Mass Effect, but without the "another test patch" debug patch.
This patch seemed to fix all the problems. I was able to get into the part of the game that was crashing before!
So, the combination of the three patches fixed it. Not including "another test patch".
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #44 from Don Hess dhess31@comcast.net 2009-04-20 18:29:45 --- (In reply to comment #43)
(In reply to comment #42)
Created an attachment (id=20570)
--> (http://bugs.winehq.org/attachment.cgi?id=20570) [details] [details]
Threading fix for buffer maps
Hi Don, Here's another patch to try. I realized that EQ2 calls the crashing buffer_map() call from a different thread, and the new GL calls do not have an ActivateContext call to deal with multithreading, and they did not have the ENTER_GL() locking calls. This patch fixes that.
Please apply it on top of the two patches that fixed Mass Effect, but without the "another test patch" debug patch.
This patch seemed to fix all the problems. I was able to get into the part of the game that was crashing before!
So, the combination of the three patches fixed it. Not including "another test patch".
By the way. Remember how i talked about WOW crashing? With these patches WOW will crash if OffScreenRenderingMode is FBO, which used to work. If it is set to pbuffer then it works fine.
However, EQ2 only displays it's shaders under FBO. So I don't know if that tells you anything or not.
At least everything seems to be working now.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #45 from Don Hess dhess31@comcast.net 2009-04-20 18:41:20 --- (In reply to comment #44)
(In reply to comment #43)
(In reply to comment #42)
Created an attachment (id=20570)
--> (http://bugs.winehq.org/attachment.cgi?id=20570) [details] [details] [details]
Threading fix for buffer maps
Hi Don, Here's another patch to try. I realized that EQ2 calls the crashing buffer_map() call from a different thread, and the new GL calls do not have an ActivateContext call to deal with multithreading, and they did not have the ENTER_GL() locking calls. This patch fixes that.
Please apply it on top of the two patches that fixed Mass Effect, but without the "another test patch" debug patch.
This patch seemed to fix all the problems. I was able to get into the part of the game that was crashing before!
So, the combination of the three patches fixed it. Not including "another test patch".
By the way. Remember how i talked about WOW crashing? With these patches WOW will crash if OffScreenRenderingMode is FBO, which used to work. If it is set to pbuffer then it works fine.
However, EQ2 only displays it's shaders under FBO. So I don't know if that tells you anything or not.
At least everything seems to be working now.
Check that. WOW doesn't work right now. It stutters when moving (the animations aren't right) and crashes after about 5 min. Should we open a different bug?
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #46 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-20 18:49:17 ---
Check that. WOW doesn't work right now. It stutters when moving (the animations aren't right) and crashes after about 5 min. Should we open a different bug?
Does it fail with the current wine code(ie, none of the patches here applied)? Or does it fail with some of the patches from this bug, but work fine with a plain wine git?
If it fails with plain wine git, file a bug. If it doesn't, please try to find the patch that breaks it. The 3 patches should be pretty much independent, and I can't see how any of them should break WoW after time. The only thing I can imagine is that glMapBuffer makes GL allocate more memory so you hit the infamous 4 GB address space limit.
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #47 from Don Hess dhess31@comcast.net 2009-04-20 18:52:04 --- (In reply to comment #46)
Check that. WOW doesn't work right now. It stutters when moving (the animations aren't right) and crashes after about 5 min. Should we open a different bug?
Does it fail with the current wine code(ie, none of the patches here applied)? Or does it fail with some of the patches from this bug, but work fine with a plain wine git?
If it fails with plain wine git, file a bug. If it doesn't, please try to find the patch that breaks it. The 3 patches should be pretty much independent, and I can't see how any of them should break WoW after time. The only thing I can imagine is that glMapBuffer makes GL allocate more memory so you hit the infamous 4 GB address space limit.
Yeah. There seems to be something wrong with my system, as reverting back to 1.1.18 STILL didn't make WOW work right. Odd.
Anyway, the patches seem to be good now.
http://bugs.winehq.org/show_bug.cgi?id=18040
DL taedium_vitae@eml.cc changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |taedium_vitae@eml.cc
--- Comment #48 from DL taedium_vitae@eml.cc 2009-04-20 20:57:16 --- Those are experiencing crashes with WOW are probably running into this bug: http://bugs.winehq.org/show_bug.cgi?id=13335
http://bugs.winehq.org/show_bug.cgi?id=18040
Chadwick Ferguson chadwick@clan-mac.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #20432|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=18040
Chadwick Ferguson chadwick@clan-mac.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #20433|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=18040
Chadwick Ferguson chadwick@clan-mac.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #20527|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #49 from Stefan Dösinger stefandoesinger@gmx.at 2009-04-21 06:13:20 --- Good, so now I just have to figure out why Crysis is still broken
http://bugs.winehq.org/show_bug.cgi?id=18040
atfrase frase@cs.wisc.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frase@cs.wisc.edu
--- Comment #50 from atfrase frase@cs.wisc.edu 2009-05-06 18:26:41 --- I'm still getting General protection fault! History: RaiseException() ... ... [C:\windows\system32\d3dx9_36.dll] __wine_stub_D3DXCompileShaderFromFileA() on Mass Effect (Steam) with wine 1.1.20. I grabbed the source from git, verified that the two patches provided here (attachments 20554,20555) are already applied, compiled, and tried running from a fresh wineprefix, with no luck. Any other ideas?
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #51 from Marcin ergo14@gmail.com 2009-05-07 03:17:28 --- do you have rendering set to FBO ? if not that the case probably
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #52 from atfrase frase@cs.wisc.edu 2009-05-07 07:55:46 --- (In reply to comment #51)
do you have rendering set to FBO ? if not that the case probably
I added HKCU\Software\Wine\Direct3D\OffscreenRenderingMode = reg_sz "fbo" with no change. I tried also adding DirectDrawRenderer = "gdi" Multisampling = "enabled" PixelShaderMode = "enabled" RenderTargetLockMode = "auto" UseGLSL = "" VertexShaderMode = "hardware" VideoMemorySize = reg_dword 0x140 (320) (geforce 8800gts 320mb) still with no change.
How do I generate a crash log to determine if my GPF has the same cause as this bug? Is it just WINEDEBUG=+d3d wine "Steam.exe" >log 2>&1 ?
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #53 from Rico kgbricola@web.de 2009-06-12 07:04:50 --- Should be fixed by commits: 3dc55010eae371c2ce0d343549b3681411bcf6f0 926fe798c50309fecb6f901e1310569d3257ff88 1fbc6e560d06e85b09b7e8460ae941cb0ba62062
Crysis is handled in bug 18799, there the source of the problem isn't really clear, yet. It looks like a memory corruption, which didn't show up before.
@atfrase You probably need a native copy of d3dx9_36.dll.
http://bugs.winehq.org/show_bug.cgi?id=18040
John P Sims jsims2359@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsims2359@gmail.com
--- Comment #54 from John P Sims jsims2359@gmail.com 2009-09-12 01:08:57 --- Using 1.1.29, Mass Effect isn't crashing for me anymore. I'm not getting any GPF windows, either. Can anyone else confirm?
http://bugs.winehq.org/show_bug.cgi?id=18040
--- Comment #55 from John P Sims jsims2359@gmail.com 2009-09-26 16:07:43 --- Using wine-1.1.30 with a clean wine prefix, Mass Effect (Steam) is not crashing.
http://bugs.winehq.org/show_bug.cgi?id=18040
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #56 from Austin English austinenglish@gmail.com 2009-09-26 20:41:27 --- No response, marking fixed.
http://bugs.winehq.org/show_bug.cgi?id=18040
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #57 from Alexandre Julliard julliard@winehq.org 2009-10-09 11:13:57 --- Closing bugs fixed in 1.1.31.
-
wine-bugs＠winehq.org