http://bugs.winehq.org/show_bug.cgi?id=20669
Summary: Certain objects found in game cause EQ2 to crash. Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: ben@walkingriver.com
While wandering around through the game, it will suddenly crash. Almost every time, it happens when an item comes into view. The objects that cause these crashes are unknown, but include crafting stations and the ykeshan bear mount.
http://bugs.winehq.org/show_bug.cgi?id=20669
Colin Wetherbee cww@denterprises.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #1 from Colin Wetherbee cww@denterprises.org 2009-11-11 18:41:03 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=20669
Colin Wetherbee cww@denterprises.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cww@denterprises.org
http://bugs.winehq.org/show_bug.cgi?id=20669
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Alias|ObjectsCrashEQ2 |
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-11 22:38:33 --- Terminal output of the crash? What video card and driver?
http://bugs.winehq.org/show_bug.cgi?id=20669
--- Comment #3 from Benjamin Callaghan ben@walkingriver.com 2009-11-12 14:56:05 --- Created an attachment (id=24706) --> (http://bugs.winehq.org/attachment.cgi?id=24706) Terminal Output of Crash
http://bugs.winehq.org/show_bug.cgi?id=20669
--- Comment #4 from Benjamin Callaghan ben@walkingriver.com 2009-11-12 14:58:18 --- I have an Nvidia Geforce 8800 GTS. I am using the Nvidia accelerated graphics (version 185) driver. It is the newest for linux and is marked reccomended
http://bugs.winehq.org/show_bug.cgi?id=20669
--- Comment #5 from Benjamin Callaghan ben@walkingriver.com 2009-11-12 15:29:32 --- Created an attachment (id=24707) --> (http://bugs.winehq.org/attachment.cgi?id=24707) Linux Terminal Output
Other output is wine showing what Windows would have shown if run from terminal.
http://bugs.winehq.org/show_bug.cgi?id=20669
Joni L-H jonilh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonilh@gmail.com
--- Comment #6 from Joni L-H jonilh@gmail.com 2009-11-23 21:06:59 --- This is the same bug as 19659 and I just tested it still remains in 1.1.33
http://bugs.winehq.org/show_bug.cgi?id=20669
--- Comment #7 from Jarod wine@faltine.com 2010-02-25 03:52:36 --- Created an attachment (id=26471) --> (http://bugs.winehq.org/attachment.cgi?id=26471) Backtraces 1.1.18 to 1.1.39
I am not sure it is the same bug as #19659 but it might be related: it looks like there are several crashes that might come from the following patch:
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.
I prefer to post here because it is exactly the symptoms I experience: certain objects found in game cause crashes. It never crashes randomly shortly after entering the game: there is always an object or a character coming into view, and I can play all night if I stay away from such objects. I never experienced a crash with version 1.1.18 yet. The patcher doesn't work for me with this version, but if I patch using 1.1.39 I can get into the game by launching EverQuest2.exe directly. I haven't noticed any difference in game between versions yet, apart from the crashes. The hardware I use is a nvidia nForce chipset 7050 with integrated video. The graphical options in game are set for "extreme performance" because it is the only setting offering a fluid game on this hardware, be it on windows or linux. I might not be experiencing some crashes other people with better hardware and better settings experience.
I made the regression test between 1.1.18 and 1.1.19 as Scott Murray did but I specifically kept testing only one thing: crafting stations, because it is easy to get in the situation and allow to get rid of any randomness in the testing. I also tested with 1.1.39 and the feb, 24 version from the git repository. I noticed it is the action of crafting, or witnessing someone who crafts, that gives a crash 100% of the time. I sometimes can look at crafting stations for a time without crashing.
The backtrace I get is always the same, as far as I can tell (see attached backtraces.tgz). In all the versions I tested there are those same lines, and a few others: wine: Unhandled page fault on read access to 0xffffffff at address 0xa768f7 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0x00a768f7).
My conclusion is that the crash I get with crafting stations hasn't changed since this patch. The other crashes might have the same cause, or not.
What I plan to do is: - stress test 1.1.18 to confirm there is no crash, even while raiding with lots of people or crafting for a long time - test the first buggy version in all situations other than crafting and record the backtraces and the object who triggered it - try to provide +d3d,+tid traces, but it is not very easy for me at is slows the machine down to a crawl. - do whatever the devs ask :)
http://bugs.winehq.org/show_bug.cgi?id=20669
--- Comment #8 from Joni L-H jonilh@gmail.com 2010-02-25 04:15:49 --- Newer versions of Wine seams to have another issue that dosent even allow the game to start at all.
And I can confirm that 1.1.18 is as stable as running it nativly on Windows. I have raided, grouped and played in almost every zone in the game for countless houers. EQ2 dose on rare occations crash under Wine 1.1.18. But same or less often than EQ2 in native Windows.
The only real bug that 1.1.18 has is the corupted textures that occur if you use Complex Shaders.
http://bugs.winehq.org/show_bug.cgi?id=20669
Colin Wetherbee cww@denterprises.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #9 from Colin Wetherbee cww@denterprises.org 2010-03-03 20:39:23 --- I've run a regression test for this and come up with the following commit as being the culprit. This is the same commit that came up as being bad for bug #19659, and it leads me to believe both bugs are caused by the same issue. In bug #19659, Stefan suggests getting a +d3d,+tid log. I guess that's the next step, then.
014c4bfc70a4d4e60f033d579d1be13a46f65170 is the 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
http://bugs.winehq.org/show_bug.cgi?id=20669
--- Comment #10 from Colin Wetherbee cww@denterprises.org 2010-03-03 21:10:00 --- (In reply to comment #9)
In bug #19659, Stefan suggests getting a +d3d,+tid log. I guess that's the next step, then.
And, here it is:
http://colinwetherbee.com/data/eq2-wine-debug-2010030301.bz2
http://bugs.winehq.org/show_bug.cgi?id=20669
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #11 from Stefan Dösinger stefandoesinger@gmx.at 2010-03-04 02:52:45 --- The buffer_map entry TRACE is printed, but the one where it prints the returned address isn't. So it is crashing somewhere in this function. The backtrace doesn't contain any helpful infos. Did you compile wine without debug symbols? You can also try to add extra traces to buffer_map in dlls/wined3d/buffer.c to find the crashing line of code.
http://bugs.winehq.org/show_bug.cgi?id=20669
--- Comment #12 from Henri Verbeet hverbeet@gmail.com 2010-03-04 06:37:54 --- (In reply to comment #11)
The buffer_map entry TRACE is printed, but the one where it prints the returned address isn't. So it is crashing somewhere in this function. The backtrace doesn't contain any helpful infos.
Well, it's clearly dereferencing a NULL pointer, possibly inside libGL.
Since the game seems to be doing quite a bit of cleanup at this point, the first thing you want to check is if you've got a *valid* GL context. You may also want to explicitly check if you return from the GL_EXTCALL's.
http://bugs.winehq.org/show_bug.cgi?id=20669
Jarod wine@faltine.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@faltine.com
--- Comment #13 from Jarod wine@faltine.com 2010-07-09 17:47:44 --- I tested with version 1.2-rc7 and I was able to craft items. Would it be that this bug was corrected at the same time as bug 19659 ? Anybody could confirm they don't have this crash with crafting stations anymore ?
http://bugs.winehq.org/show_bug.cgi?id=20669
--- Comment #14 from Joni L-H jonilh@gmail.com 2010-07-09 17:59:26 --- As I pointed out before I believe this bug is a duplicate of bug 19659 And I can confirm that crafting stations dose no longer causes crash.
http://bugs.winehq.org/show_bug.cgi?id=20669
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dank@kegel.com Resolution| |DUPLICATE
--- Comment #15 from Dan Kegel dank@kegel.com 2010-07-09 19:07:24 --- Same culprit commit, works now -> dup
*** This bug has been marked as a duplicate of bug 19659 ***
http://bugs.winehq.org/show_bug.cgi?id=20669
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Jeff Zaroyko jeffz@jeffz.name 2010-07-09 21:36:39 --- Closing duplicate.