| Bug ID | 96835 |
|---|---|
| Summary | "gallium: Force blend color to 16-byte alignment" c= rash with "-march=3Dnative -O3" causes some 32bit games to crash |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | raffarti@zoho.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Building mesa with "-march=3Dnative -O3" causes some= 32 bit games to crash at start since "gallium: Force blend color to 16-byte alignment" pat= ch (d8d6091a846ac2a40a011d512d6d57f6c8442e6a). This happens using both opengl = or nine. Everything works as expected using "-march=3Dnative -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
| What | Removed | Added |
|---|---|---|
| CC | chuck.atkins@kitware.com |
Created attachment 124940 [details]
steam gdb backtrace
Steam crashes (it's 32 bit)
The backtrace looks completely unrelated to the commit you cit= e. 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)?
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.
Created attachment 124947 [details]
steam gdb stack trace with gallium hud and mesa debug
Created attachment 124948 [details]
steam gdb stack trace without gallium hud and mesa debug
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.)
| What | Removed | Added |
|---|---|---|
| QA Contact | dri-devel@lists.freedesktop.org | mesa-dev@lists.freedesktop.org |
| Component | Drivers/Gallium/radeonsi | Mesa core |
| Assignee | dri-devel@lists.freedesktop.org | mesa-dev@lists.freedesktop.org |
(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=3D0x569cbfc8, 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.