| Summary: | Guns of Icarus Online segfaults on startup since AMDGPU: Partially fix control flow at -O0 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Daniel Scharrer <daniel> |
| Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | normal | ||
| Priority: | medium | CC: | arsenm2, daniel |
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Short Guns of Icarus Online startup trace (truncated by segfault)
Backtraces recorded for the crashes R600_DEBUG=vs,tcs,tes,gs,ps,cs log Another R600_DEBUG=vs,tcs,tes,gs,ps,cs log Valgrind log |
||
|
Description
Daniel Scharrer
2016-10-03 12:58:30 UTC
Please attach a backtrace of a segfault. Created attachment 126992 [details]
Backtraces recorded for the crashes
Here is a list of backtraces I have seen - it's probably not complete.
I haven't been able to reproduce this with Mesa master and LLVM r283219 so far. Does this happen with clean re-builds? If this still happens with current LLVM and clean re-builds, please provide logs with R600_DEBUG=vs,tcs,tes,gs,ps,cs. The wide range of different backtraces suggests that it might be random memory corruption, so running under Valgrind may also be worth a shot. Created attachment 127001 [details] R600_DEBUG=vs,tcs,tes,gs,ps,cs log (In reply to Nicolai Hähnle from comment #3) > I haven't been able to reproduce this with Mesa master and LLVM r283219 so > far. Does this happen with clean re-builds? Yes, all LLVM and Mesa builds were done through the package manager, starting with an empty build directory. And I don't use ccache. I just re-checked with an updated LLVM & Mesa and the game still crashes: Mesa: git-0e85ff3 LLVM: r283225 I also verified that it still starts properly with amdgpu-pro (running on top of the upstream 4.7.5 amdgpu module). > If this still happens with current LLVM and clean re-builds, please provide > logs with R600_DEBUG=vs,tcs,tes,gs,ps,cs. > > The wide range of different backtraces suggests that it might be random > memory corruption, so running under Valgrind may also be worth a shot. It does look like it. I'll get a valgrind memcheck log, but will first need to recompile a couple of libraries because valgrind still doesn't support all the instructions of my CPU :/ Created attachment 127002 [details]
Another R600_DEBUG=vs,tcs,tes,gs,ps,cs log
Looks like the crashes don't always happen for the same shader.
Created attachment 127008 [details]
Valgrind log
I managed to get a Valgrind log, the backtrace of the first invalid read seems consistent.
Here are the options I used, let me know if you want me to try any others:
valgrind --tool=memcheck --error-limit=no --log-file=valgrind-%p.log -v --trace-children=yes --track-origins=yes --read-var-info=yes --redzone-size=1024 --
I also noticed that the game's engine (Unity) overrides operator new and friends, maybe that's involved somehow.
Thanks for the additional info. Running llc on those shaders under Valgrind doesn't show anything either, but this may be a limitation of Valgrind in connection with LLVM's internal allocator. That this is exposed by the game's operator overrides is curious. If the bisection result is solid, we can't put the blame on those overrides though. Careful inspection of the commit you bisected this to has lead me to a smoking gun. Could you please check whether the patch at https://reviews.llvm.org/D25306 fixes this for you? Your patch from D25306 fixes the crash for me. Thanks for looking into this. Fixed in LLVM r283528. |
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.