Bug 89084 - dungeon defenders crashes after vbo_exec_DrawRangeElements call
Summary: dungeon defenders crashes after vbo_exec_DrawRangeElements call
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-11 14:10 UTC by Karol Herbst
Modified: 2016-11-02 07:18 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
backtrace of the crash (3.79 KB, text/plain)
2015-02-11 14:10 UTC, Karol Herbst
Details
valgrind output (43.54 KB, text/plain)
2015-02-13 14:47 UTC, Karol Herbst
Details
valgrind output (287.02 KB, text/plain)
2015-02-13 18:07 UTC, Karol Herbst
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karol Herbst 2015-02-11 14:10:16 UTC
Created attachment 113354 [details]
backtrace of the crash

There is a bugzilla entry for the game already: https://bugzilla.icculus.org/show_bug.cgi?id=5847

I was curious if mesa could validate the input of the vbo_exec_DrawRangeElements call to return an error instead of segfaulting later on, even if this is an application bug.

If there is nothing mesa can do, because of integrity with OpenGL specs I am fine with a CLOSED-INVALID, but it would be nice to have some optional workarounds nethertheless.

mesa-e68b67b53fce39a8c93188262d9e795ca50750ac used for the backtrace.
Comment 1 Eero Tamminen 2015-02-12 16:36:28 UTC
Does Valgrind tell anything additional about the issue?
Comment 2 Karol Herbst 2015-02-12 16:39:47 UTC
didn't check yet. Will do later when I have time.
Comment 3 Karol Herbst 2015-02-13 14:47:14 UTC
Created attachment 113464 [details]
valgrind output

sadly I can't debug further with the steam version, so I have to check if I also have a non-steam version somwhere. But there are some invalid write of size 4 from mesa, which I think may libsdl2 or mesa bugs itself or maybe it should be that way.
Comment 4 Eero Tamminen 2015-02-13 15:31:37 UTC
(In reply to Karol Herbst from comment #3)
> Created attachment 113464 [details]
> valgrind output

Thanks!

> sadly I can't debug further with the steam version, so I have to check if I
> also have a non-steam version somwhere. But there are some invalid write of
> size 4 from mesa, which I think may libsdl2 or mesa bugs itself or maybe it
> should be that way.

This could be Valgrind not knowing where the memory came from.  Only if your libdrm library is built with Valgrind devel files present in the system, it will annotate the memory it returns from kernel for Valgrind.

On Ubuntu 14.10, the necessary files come with "valgrind" package, but libdrm needs to be (re-)build after that is installed.

Another issue is that for Valgrind backtraces to be useful, Mesa debug symbols are needed, so that we can see where (which source file/line) the Valgrind warnings are coming from.

Could you fix those issues and attach updated Valgrind output?
Comment 5 Karol Herbst 2015-02-13 18:07:48 UTC
Created attachment 113475 [details]
valgrind output

sadly there comes nothing more, because valgrind seems to be inside a 100% cpu loop. I will try to get a better output with a non-steam version (I got the game from humblebundle, so this is easy)

(In reply to Eero Tamminen from comment #4)
> (In reply to Karol Herbst from comment #3)
> > Created attachment 113464 [details]
> > valgrind output
> 
> Thanks!
> 
> > sadly I can't debug further with the steam version, so I have to check if I
> > also have a non-steam version somwhere. But there are some invalid write of
> > size 4 from mesa, which I think may libsdl2 or mesa bugs itself or maybe it
> > should be that way.
> 
> This could be Valgrind not knowing where the memory came from.  Only if your
> libdrm library is built with Valgrind devel files present in the system, it
> will annotate the memory it returns from kernel for Valgrind.
> 
> On Ubuntu 14.10, the necessary files come with "valgrind" package, but
> libdrm needs to be (re-)build after that is installed.
> 
> Another issue is that for Valgrind backtraces to be useful, Mesa debug
> symbols are needed, so that we can see where (which source file/line) the
> Valgrind warnings are coming from.
> 
> Could you fix those issues and attach updated Valgrind output?

I am using Gentoo/Linux, but valgrind for some reasons didn't want to read my external debug files, so I had to rebuild the libraries without stripping the binaries, which obviously worked.

I will upload a new valgrind output file after I get the new game files and can try again. As it seems the issue inside mesa could be false alarms or not important at all.
Comment 6 Karol Herbst 2015-10-04 15:12:32 UTC
I created an apitrace of the game because of some visual artifacts with nouveau and glretrace just crashes with intel and nouveau
Comment 7 Matt Turner 2016-11-02 07:18:42 UTC
(In reply to Karol Herbst from comment #5)
> I am using Gentoo/Linux, but valgrind for some reasons didn't want to read
> my external debug files, so I had to rebuild the libraries without stripping
> the binaries, which obviously worked.

You want:

mattst88@macbook ~ % cat /etc/portage/env/splitdebug.conf 
CFLAGS="$CFLAGS -ggdb3"
CXXFLAGS="$CFLAGS"
FEATURES="splitdebug"
mattst88@macbook ~ % cat /etc/portage/package.env/splitdebug 
sys-libs/glibc splitdebug.conf

and make sure to compile libdrm with USE=valgrind.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.