http://bugs.winehq.org/show_bug.cgi?id=22000
Summary: Gallium + Indexed rendering = Null pointer dereference Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: MostAwesomeDude@gmail.com
Created an attachment (id=26727) --> (http://bugs.winehq.org/attachment.cgi?id=26727) Failed device.ok test in d3d9
First off, I *am* upstream (Mesa/Gallium), so assume they've been contacted. :3
Gallium and indexed rendering are not very happy with each other. I get some fairly solidly reliable segfaults with both a d3d9 DLL test (device.ok) and Civ4 (Steam version). Hardware is a Radeon R580 (X1900), driver is r300g from Mesa git.
I'm attaching four logs. The first two are the original test and Civ4 logs; the second two are the same, but edited to show the juicy bits.
My current guess, based on the Mesa debug info I dumped, is that the indexed rendering code is slightly baked and maybe trusting the underlying GL driver a bit too much.
get_arrays_bounds: Handling 2 attrs attr 0: stride 16 size 12 start (nil) end 0xfffffffc attr 1: stride 16 size 4 start 0xc end (nil) buffer range: (nil) 0xfffffffc range -4 max index 4294967295
So right here (from device.ok) we have interleaved userspace VBO, that is being prepped inside core Mesa. Two delightful things here; the first attr seems way off-base, it shouldn't dare be giving us bad pointers, and the second attr's pointers don't even line up! Compare to a sane program (Mesa's drawarrays):
get_arrays_bounds: Handling 2 attrs attr 0: stride 16 size 12 start 0x8087020 end 0x808705c attr 1: stride 16 size 4 start 0x808702c end 0x8087060 buffer range: 0x8087020 0x8087060 range 64 max index 3
r300g doesn't really care. The kernel drops the rendering on the floor for a variety of reasons, not least being the ridiculous max_index.
But then it segfaults, and I have zero idea why. I'd guess it's something to do with tossing around NULL pointers like candy, but I'm honestly not sure and I haven't really dug into the DLL code yet.
http://bugs.winehq.org/show_bug.cgi?id=22000
--- Comment #1 from Corbin Simpson MostAwesomeDude@gmail.com 2010-03-10 06:39:45 --- Created an attachment (id=26728) --> (http://bugs.winehq.org/attachment.cgi?id=26728) Civ4 log/backtrace
http://bugs.winehq.org/show_bug.cgi?id=22000
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2010-03-10 07:44:23 --- Please specify your Wine version.
http://bugs.winehq.org/show_bug.cgi?id=22000
Corbin Simpson MostAwesomeDude@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.1.38
--- Comment #3 from Corbin Simpson MostAwesomeDude@gmail.com 2010-03-10 07:46:05 --- (In reply to comment #2)
Please specify your Wine version.
Set to 1.1.38, the version in my Fedora. Also happens with git.
http://bugs.winehq.org/show_bug.cgi?id=22000
--- Comment #4 from Corbin Simpson MostAwesomeDude@gmail.com 2010-03-12 05:57:08 --- Partially fixed. The bad indices were an internal Mesa issue and I've already committed a fix, but the segfaults remain. There's definite heap corruption during the d3d9 tests, during context destruction. Steam straight-up segfaults while trying to launch Civ4. I think the two are related and have the same origin, but I haven't nailed it down yet.
http://bugs.winehq.org/show_bug.cgi?id=22000
--- Comment #5 from Austin English austinenglish@gmail.com 2010-03-12 11:09:57 --- (In reply to comment #4)
Partially fixed. The bad indices were an internal Mesa issue and I've already committed a fix, but the segfaults remain. There's definite heap corruption during the d3d9 tests, during context destruction. Steam straight-up segfaults while trying to launch Civ4. I think the two are related and have the same origin, but I haven't nailed it down yet.
Have you tried running with 'WINEDEBUG=+heap make device.ok' ?
http://bugs.winehq.org/show_bug.cgi?id=22000
--- Comment #6 from Corbin Simpson MostAwesomeDude@gmail.com 2010-03-22 05:05:01 --- (In reply to comment #5)
Have you tried running with 'WINEDEBUG=+heap make device.ok' ?
Yes, attaching that log now.
http://bugs.winehq.org/show_bug.cgi?id=22000
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #7 from Wylda wylda@volny.cz 2010-04-23 11:40:58 --- (In reply to comment #6)
Yes, attaching that log now.
Lost in space? :)
http://bugs.winehq.org/show_bug.cgi?id=22000
--- Comment #8 from Corbin Simpson MostAwesomeDude@gmail.com 2010-04-23 12:24:23 --- Sorry for not responding quickly; I kind of wandered off and forgot about this. Anyway, the log is at http://paste.pocoo.org/show/205399/. Can't attach it, it's too big. Looks impossible-to-read from my point of view, but maybe you guys can interpret it better. :3
I'll make a better effort to not take a month to respond next time.
http://bugs.winehq.org/show_bug.cgi?id=22000
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #9 from joaopa jeremielapuree@yahoo.fr 2011-06-09 13:35:14 CDT --- still a bug in currentt git?
http://bugs.winehq.org/show_bug.cgi?id=22000
--- Comment #10 from joaopa jeremielapuree@yahoo.fr 2011-07-09 09:10:25 CDT --- no news since 1 year. This bug could be closed as ABANDONED.
http://bugs.winehq.org/show_bug.cgi?id=22000
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |ABANDONED
--- Comment #11 from Austin English austinenglish@gmail.com 2011-07-10 14:07:32 CDT --- (In reply to comment #10)
no news since 1 year. This bug could be closed as ABANDONED.
Abandoned.
http://bugs.winehq.org/show_bug.cgi?id=22000
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Jeff Zaroyko jeffz@jeffz.name 2011-07-11 16:24:26 CDT --- Closing abandoned.