| Summary: | "high fidelity": Segfault in _mesa_program_resource_find_name | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Christoph Haag <haagch> |
| Component: | Drivers/DRI/i965 | Assignee: | Tapani Pälli <lemody> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | eero.t.tamminen, mark.a.janes |
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
full backtrace
apitrace trace |
||
|
Description
Christoph Haag
2015-06-10 11:41:36 UTC
Would it be possible to get apitrace dump of the application? Created attachment 116423 [details]
apitrace trace
Hm. More or less.
apitrace doesn't seem to like that much.
The program seems to segfault even if I revert 222e5b8 which changes glGetAttribLocation implementation. This makes it painful to know if my fix for this bug works correctly :/ Program received signal SIGSEGV, Segmentation fault. 0x00000000004c03a4 in retrace_glGetAttribLocation(trace::Call&) () This is a strange bug, the ir_variable in question seems to have NULL as it's name, I need to dig out if this is a valid condition, code currently assumes that everything has at least some name. I think what happens is that during linking we add resource but only later on this resource gets deleted by the backend (decides it is not used/active). This is a bit strange pattern, typically unused variables get dropped already early. Will investigate what should be done here. OK, now I know what is going on. This is actually major issue with the current implementation. Like said in comment #4, we are creating ProgramResourceList too early. Backend driver will still do optimization and is still able to remove dead code, thus removing variables that are in the resource list. The solution is to move resource list creation up in the linking to happen only after backend LinkShader hook and remove symbol table usage from the list creation (symbol table usage was just optimization instead of iterating whole IR to find variables). Ah fortunately it seems dead code removal works just fine after all! It's just me building the list using a symbol table that still contains removed variables. I will change the list creation to not use symbol table. (In reply to Tapani Pälli from comment #6) > Ah fortunately it seems dead code removal works just fine after all! It's > just me building the list using a symbol table that still contains removed > variables. I will change the list creation to not use symbol table. correction, I will change list creation to not use symbol table + move the program resource list creation to happen after backend LinkShader hook. fixed in master Can confirm, High Fidelity works fine now. Thanks a lot. Please leave a comment noting the commit that fixed it. commit f045b8b2ff5ac75da3e092f482fd1717571d8462 Author: Tapani Pälli <tapani.palli@intel.com> Date: Mon Jun 29 15:23:45 2015 +0300 glsl: create program resource list after LinkShader Resource list can be created properly only after LinkShader hook has been called to make sure all dead variables have been removed. Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Martin Peres <martin.peres@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90925 I have been bisecting dEQP regressions for 10.6. It appears that several 10.6 dEQP regressions are fixed by the commit that fixes this bug. Tapani, is it possible to backport this fix to 10.6? (In reply to Mark Janes from comment #12) > I have been bisecting dEQP regressions for 10.6. It appears that several > 10.6 dEQP regressions are fixed by the commit that fixes this bug. > > Tapani, is it possible to backport this fix to 10.6? Sure, will do. |
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.