Bug 107096

Summary:	GLSL disk cache: blob format changes may cause segfaults etc.
Product:	Mesa	Reporter:	Darren Salt <bugspam>
Component:	glsl-compiler	Assignee:	mesa-dev
Status:	RESOLVED NOTABUG	QA Contact:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Darren Salt 2018-07-03 05:44:54 UTC

Test case: “Deus Ex: Mankind Divided”. GPU is RX 470.

This was working fine with Mesa 18.1.1 installed but stopped working (symptom was a strcmp() segfaulting due to one parameter being NULL) with 18.1.3 installed. I tested 18.1.2; that worked fine. (This game crashes on first run after installing a different version of Mesa, but I'm not concerned with that here.)

Clearing Steam's shader cache for this game and running with 18.1.3 works fine (and the new cache content would, I expect, cause problems with 18.1.2 and earlier).

I went looking for patches which messed with cache content and reverted one which adds more data; with the original cached shaders, 18.1.3 suddenly started working without problems.

The commit which I reverted is 915d9166bf4c “glsl: serialize data from glTransformFeedbackVaryings”, which is commit ab2643e4b06f in master. I suspect that 99c6cae22780 “glsl/cache: save and restore ExternalSamplersUsed” and other such patches will cause similar breakage.

Changes to the on-disk shader cache format should cause a cache version bump. This doesn't seem to be happening…

Comment 1 Darren Salt 2018-07-03 06:03:01 UTC

For some reason, I just looked at debian/changelog and the datestamp of radeonsi_dri.so…

I think that it's safe to ascribe this to an interaction between the Debian build system, Mesa's expectations, and me not bothering to change the date stamp of the latest entry (or, for that matter, anything else) in debian/changelog (though there's a good reason for this: if I do that, I have to do an i386 build as well as my usual amd64 build in order to avoid dpkg throwing errors at me at install time (and I don't normally have the necessary environment for that set up).

Comment 2 Michel Dänzer 2018-07-03 08:13:33 UTC

I'm afraid you'll have to live with changing the debian/changelog timestamp when anything changes in the tree which may affect the resulting binaries.

This is a side effect of Debian's reproducible builds effort, not an upstream bug.

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.