|Summary:||"gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash|
|Status:||RESOLVED WORKSFORME||QA Contact:||mesa-dev|
|i915 platform:||i915 features:|
steam gdb backtrace
steam gdb stack trace with gallium hud and mesa debug
steam gdb stack trace without gallium hud and mesa debug
Description raffarti 2016-07-06 23:05:24 UTC
Building mesa with "-march=native -O3" causes some 32 bit games to crash at start since "gallium: Force blend color to 16-byte alignment" patch (d8d6091a846ac2a40a011d512d6d57f6c8442e6a). This happens using both opengl or nine. Everything works as expected using "-march=native -O2". tested games are: Native: The Talos Princible (32 bit) -- Always crash The Talos Princible (64 bit) -- Works Wine (32bit): League of Legends -- Always crash World of Warcraft 1.21 -- Always crash World of Warcraft 2.4.3 -- Sometimes crashes World of Warcraft 3.3.5 -- Most times works
Comment 1 Michel Dänzer 2016-07-07 00:43:16 UTC
Please attach a gdb backtrace of a crash.
Comment 2 raffarti 2016-07-07 07:17:31 UTC
Created attachment 124940 [details] steam gdb backtrace Steam crashes (it's 32 bit)
Comment 3 Nicolai Hähnle 2016-07-07 13:17:02 UTC
The backtrace looks completely unrelated to the commit you cite. Why do you think that this particular commit is at fault? Just to be sure, could you please provide a backtrace with debug symbols enabled (-g)?
Comment 4 raffarti 2016-07-07 16:37:13 UTC
The previous commit does just fine, this one does not. I've found the traces to be different with and without the gallium hud, so I'm attaching both traces.
Comment 5 raffarti 2016-07-07 16:38:20 UTC
Created attachment 124947 [details] steam gdb stack trace with gallium hud and mesa debug
Comment 6 raffarti 2016-07-07 16:38:57 UTC
Created attachment 124948 [details] steam gdb stack trace without gallium hud and mesa debug
Comment 7 Roland Scheidegger 2016-07-08 03:11:43 UTC
On second look, I am actually wondering if that commit really is doing the right thing. Shouldn't we try to set the alignment on the struct itself instead? And regardless, if someone uses an ordinary malloc for it it's not going to be aligned anyway (meaning if it's passed to drivers somewhere and the called functions are relying on this to be aligned they might be in for some surprise). (That said I have no idea if this is really related to this bug.)
Comment 8 Nicolai Hähnle 2016-07-08 09:13:36 UTC
(The Gallium HUD crash is "benign": you enabled more graphs than there are pre-defined colors. Annoying, but unrelated to the problem at hand.) My understanding is that malloc should return pointers with the largest alignment requirement possible for the size that it allocates. Although, perhaps that's less than 16 bytes on 32 bits? Actually, I think that's it: the backtrace shows ctx=0x569cbfc8, i.e. ctx is only 8-byte aligned even though it contains a pipe_blend_color structure. Moving to Mesa core since it's not really radeonsi-specific.
Comment 9 Nicolai Hähnle 2016-07-12 11:41:21 UTC
Could you please try whether the patch at https://patchwork.freedesktop.org/patch/98293/ fixes those crashes for you?
Comment 10 raffarti 2016-07-12 14:06:38 UTC
(In reply to Nicolai Hähnle from comment #9) > Could you please try whether the patch at > https://patchwork.freedesktop.org/patch/98293/ fixes those crashes for you? Everything I've tested so far is working now.
Comment 11 i.kalvachev 2016-07-14 00:01:37 UTC
I would actually recommend solving the problem in its root. Disable auto vectorization. FFmpeg recently tried removing "-fno-tree-vectorize" for gcc >=4.9 . After a few weeks they reverted the change. It caused a bunch of strange regressions, breakages and ICE. That features has been around for nine years and it is still buggy. Save yourself some headaches and disable it.