Bug 96835 - "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash
Summary: "gallium: Force blend color to 16-byte alignment" crash with "-march=native -...
Status: RESOLVED WORKSFORME
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-06 23:05 UTC by raffarti
Modified: 2016-07-14 00:01 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
steam gdb backtrace (1.48 KB, text/plain)
2016-07-07 07:17 UTC, raffarti 		Details
steam gdb stack trace with gallium hud and mesa debug (2.85 KB, text/plain)
2016-07-07 16:38 UTC, raffarti 		Details
steam gdb stack trace without gallium hud and mesa debug (3.15 KB, text/plain)
2016-07-07 16:38 UTC, raffarti 		Details
View All

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.

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.