| Summary: | "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | raffarti |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED WORKSFORME | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | chuck.atkins |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
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
Please attach a gdb backtrace of a crash. Created attachment 124940 [details]
steam gdb backtrace
Steam crashes (it's 32 bit)
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)? 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.) (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. Could you please try whether the patch at https://patchwork.freedesktop.org/patch/98293/ fixes those crashes for you? (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. 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.