Does Valgrind tell anything additional about the issue?

didn't check yet. Will do later when I have time.

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.

(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?

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.

I created an apitrace of the game because of some visual artifacts with nouveau and glretrace just crashes with intel and nouveau

(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.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1470.