Bug 109543 - After upgrade mesa to 19.0.0~rc1 all vulkan based application stop working ["vulkan-cube" received SIGSEGV in radv_pipeline_init_blend_state at ../src/amd/vulkan/radv_pipeline.c:699]
Summary: After upgrade mesa to 19.0.0~rc1 all vulkan based application stop working ["...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/radeon (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: mesa-19.0
  Show dependency treegraph
 
Reported: 2019-02-04 10:55 UTC by mikhail.v.gavrilov
Modified: 2019-02-12 13:51 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
rise_of_tomb_rider backtrace (186.69 KB, text/plain)
2019-02-04 10:55 UTC, mikhail.v.gavrilov
Details
vulkan-cube backtrace (26.50 KB, text/plain)
2019-02-04 10:55 UTC, mikhail.v.gavrilov
Details
vulkan-cube backtrace + mesa 19.0.0 rc2 (26.55 KB, text/plain)
2019-02-07 18:07 UTC, mikhail.v.gavrilov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mikhail.v.gavrilov 2019-02-04 10:55:08 UTC
Created attachment 143284 [details]
rise_of_tomb_rider backtrace

Yesterday I tried update mesa to 19.0.0~rc1 version, but after update all
vulkan based application stop working.

List of tested application:
- Rise of the Tomb Raider (backtrace is attached)
- F1 2017
- Any game launched via steam play DXVK
- vulkan-cube (backtrace is attached)

Last working mesa version:
18.3.2-1
Comment 1 mikhail.v.gavrilov 2019-02-04 10:55:39 UTC
Created attachment 143285 [details]
vulkan-cube backtrace
Comment 2 Samuel Pitoiset 2019-02-04 20:24:30 UTC
It seems like we can't reproduce the problem. Where your mesa comes from?
Comment 3 mikhail.v.gavrilov 2019-02-04 20:35:32 UTC
(In reply to Samuel Pitoiset from comment #2)
> It seems like we can't reproduce the problem. Where your mesa comes from?

https://koji.fedoraproject.org/koji/buildinfo?buildID=1183327
Comment 4 Sylvain BERTRAND 2019-02-05 01:09:21 UTC
Tested Rise of the Tomb Raider : I get a system hang (I am going to report a regression because I did clear the game on 04/2018).
No pb with dota2 vulkan, artifact (vulkan) or cs:go (opengl)
I use a gfx stack git from sunday: linux (amd-staging-drm-next), drm, llvm, mesa-gl, mesa-vulkan, xserver, xf86-video-amdgpu
Comment 5 mikhail.v.gavrilov 2019-02-05 05:21:15 UTC
Which gcc versiob do you use?(In reply to Sylvain BERTRAND from comment #4)
> Tested Rise of the Tomb Raider : I get a system hang (I am going to report a
> regression because I did clear the game on 04/2018).
> No pb with dota2 vulkan, artifact (vulkan) or cs:go (opengl)
> I use a gfx stack git from sunday: linux (amd-staging-drm-next), drm, llvm,
> mesa-gl, mesa-vulkan, xserver, xf86-video-amdgpu

Which gcc version do you use?

Fedora already moved to gcc 9.0.1
Comment 6 Samuel Pitoiset 2019-02-07 08:24:50 UTC
Could be an issue related to GCC 9.
Comment 7 mikhail.v.gavrilov 2019-02-07 08:35:02 UTC
(In reply to Samuel Pitoiset from comment #6)
> Could be an issue related to GCC 9.

Can you test MESA with GCC9 ?
Comment 8 mikhail.v.gavrilov 2019-02-07 18:07:48 UTC
Created attachment 143323 [details]
vulkan-cube backtrace + mesa 19.0.0 rc2
Comment 9 mikhail.v.gavrilov 2019-02-07 18:09:05 UTC
With mesa 19.0.0 rc2 I has same crashes.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1206254
Comment 10 Gustaw Smolarczyk 2019-02-07 19:00:23 UTC
Hi,

After messing for a while with godbolt, it seems like GCC 9 considers literal scope to end with a block and not a function [1], or at least this is my assumption. In the godbolt example you can see the "1" assignments being dropped from the assembly when they are inside the switch scope.

When a literal assignment (like the following in radv_meta_blit.c build_pipeline function) happens inside a switch case, GCC 9 probably drops it:

--- SNIP ---

switch(aspect) {
case VK_IMAGE_ASPECT_COLOR_BIT:
	vk_pipeline_info.pColorBlendState = &(VkPipelineColorBlendStateCreateInfo) {
		.sType = VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_STATE_CREATE_INFO,
		.attachmentCount = 1,
		.pAttachments = (VkPipelineColorBlendAttachmentState []) {
			{ .colorWriteMask =
			VK_COLOR_COMPONENT_A_BIT |
			VK_COLOR_COMPONENT_R_BIT |
			VK_COLOR_COMPONENT_G_BIT |
			VK_COLOR_COMPONENT_B_BIT },
		}
	};
	break;

--- SNIP ---

You could work this around by giving names to the literals and putting them in the function scope (not inside any block). As I am not familiar with the C standard, I am not sure if what GCC 9 assumes is legal or not.


[1] https://godbolt.org/z/wTuMH-
Comment 11 Igor Gnatenko 2019-02-08 09:49:14 UTC
https://www.gnu.org/software/gcc/gcc-9/porting_to.html

Block scope compound literal's lifetime

The C standard says that compound literals which occur inside of the body of a function have automatic storage duration associated with the enclosing block. Older GCC releases were putting such compound literals into the scope of the whole function, so their lifetime actually ended at the end of containing function. This has been fixed in GCC 9. Code that relied on this extended lifetime needs to be fixed, move the compound literals to whatever scope they need to accessible in.


      struct S { int a, b; };
      int foo(void) {
        // The following line no longer compiles
        struct S *p = &({ (struct S) { 1, 2 }; });
        struct S *q;
        {
          q = &(struct S) { 3, 4 };
        }
        // This is invalid use after lifetime of the compound literal
        // ended.
        return q->b;
      }
Comment 12 Samuel Pitoiset 2019-02-11 09:15:59 UTC
Should be fixed with https://patchwork.freedesktop.org/series/56485/
Comment 13 mikhail.v.gavrilov 2019-02-12 04:48:21 UTC
(In reply to Samuel Pitoiset from comment #12)
> Should be fixed with https://patchwork.freedesktop.org/series/56485/

Thanks. I tested this patch and can confirm that problem was fixed.
Comment 14 Samuel Pitoiset 2019-02-12 13:51:30 UTC
Fixed.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=129a9f4937b8f2adb4d37999677d748d816d611c

-rc3 will have the fix.


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.