While running wine's direct3d tests (which invoke OpenGL), I noticed that I got a lot of crashes, with poor debugging info: Backtrace: =>0 0x063bcd77 in swrast_dri.so (+0x59d77) (0x1535f9c0) 1 0x063bd6d9 in swrast_dri.so (+0x5a6d8) (0x00000000) 2 0x063c11de in swrast_dri.so (+0x5e1dd) (0x00000000) 3 0x0659825e in swrast_dri.so (+0x23525d) (0x1535f7f0) 4 0x066dadf3 in swrast_dri.so (+0x377df2) (0x1535f7f0) 5 0x066d9abf in swrast_dri.so (+0x376abe) (0x1535f3a8) 6 0x05cf1959 in libgl.so.1 (+0x3e958) (0x1535f3a8) 7 0x05cca866 glXMakeContextCurrent+0x95() in libgl.so.1 (0x0460c3c0) 8 0x05ccaa86 glXMakeCurrent+0x15() in libgl.so.1 (0x04b8f2d8) 9 0x05935782 X11DRV_WineGL_InitOpenglInfo+0x2fe() [/home/austin/wine-valgrind/dlls/winex11.drv/opengl.c:502] in winex11 (0x04b8f2d8) 10 0x05936f92 init_opengl+0xfbe(once=0x5993e00, param=0x0(nil), context=(nil)) [/home/austin/wine-valgrind/dlls/winex11.drv/opengl.c:679] in winex11 (0x04b8f4e8) This is on gentoo, and llvm/clang/mesa all have USE=debug (mesa also has USE=valgrind enabled). After debugging with some Wine guys, it was pointed out to me that march=native can cause issues. Removing march=core17 from my system CFLAGS and recompiling mesa (nothing else), I got much better info from valgrind: ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so device && touch device.ok preloader: Warning: failed to reserve range 00110000-68000000 preloader: Warning: failed to reserve range 7f000000-82000000 ==22129== ==22129== Process terminating with default action of signal 11 (SIGSEGV) ==22129== General Protection Fault ==22129== at 0x7BC8DBC5: setup_exception_record (signal_i386.c:1756) ==22129== by 0x7BC8E8C7: segv_handler (signal_i386.c:2094) ==22129== by 0x42532EF: ??? (in /lib32/libpthread-2.23.so) ==22129== ==22129== Process terminating with default action of signal 11 (SIGSEGV) ==22129== General Protection Fault ==22129== at 0x400E324: _dl_fixup (dl-runtime.c:101) ==22129== by 0x401494F: _dl_runtime_resolve (dl-trampoline.S:43) ==22129== by 0x402556D: _vgnU_freeres (vg_preloaded.c:77) ==22129== by 0x7BC8DB8F: setup_exception_record (signal_i386.c:1756) ==22129== by 0x7BC8E8C7: segv_handler (signal_i386.c:2094) ==22129== by 0x42532EF: ??? (in /lib32/libpthread-2.23.so) ==22129== 8 bytes in 2 blocks are possibly lost in loss record 145 of 3,647 ==22129== at 0x402D2A6: memalign (vg_replace_malloc.c:858) ==22129== by 0x401133C: allocate_and_init (dl-tls.c:603) ==22129== by 0x401133C: tls_get_addr_tail (dl-tls.c:791) ==22129== by 0x4011F81: ___tls_get_addr (dl-tls.c:837) ==22129== by 0x74526E3: __libelf_seterrno (elf_error.c:331) ==22129== by 0x745F549: gelf_getsym (gelf_getsym.c:71) ==22129== by 0x6C64888: parse_symbol_table (radeon_elf_util.c:54) ==22129== by 0x6C64888: radeon_elf_read (radeon_elf_util.c:160) ==22129== by 0x6B93C3D: si_llvm_compile (si_shader_tgsi_setup.c:251) ==22129== by 0x6B8DF9E: si_compile_llvm (si_shader.c:6426) ==22129== by 0x6B8EDC0: si_compile_tgsi_shader (si_shader.c:7631) ==22129== by 0x6BA684F: si_init_shader_selector_async (si_state_shaders.c:1343) ==22129== by 0x68C00EE: util_queue_thread_func (u_queue.c:154) ==22129== by 0x68BFC44: impl_thrd_routine (threads_posix.h:87) ==22129== by 0x4249260: start_thread (pthread_create.c:333) ==22129== by 0x434531D: clone (clone.S:114) ==22129== Let me know if I can provide more info to help debug this.
Actually, those are probably distinct issues, and it's not clear to me (yet) whether the latter is a Valgrind issue. (In reply to Austin English from comment #0) > While running wine's direct3d tests (which invoke OpenGL), I noticed that I > got a lot of crashes, with poor debugging info: > Backtrace: > =>0 0x063bcd77 in swrast_dri.so (+0x59d77) (0x1535f9c0) > 1 0x063bd6d9 in swrast_dri.so (+0x5a6d8) (0x00000000) > 2 0x063c11de in swrast_dri.so (+0x5e1dd) (0x00000000) > 3 0x0659825e in swrast_dri.so (+0x23525d) (0x1535f7f0) > 4 0x066dadf3 in swrast_dri.so (+0x377df2) (0x1535f7f0) > 5 0x066d9abf in swrast_dri.so (+0x376abe) (0x1535f3a8) > 6 0x05cf1959 in libgl.so.1 (+0x3e958) (0x1535f3a8) > 7 0x05cca866 glXMakeContextCurrent+0x95() in libgl.so.1 (0x0460c3c0) > 8 0x05ccaa86 glXMakeCurrent+0x15() in libgl.so.1 (0x04b8f2d8) > 9 0x05935782 X11DRV_WineGL_InitOpenglInfo+0x2fe() > [/home/austin/wine-valgrind/dlls/winex11.drv/opengl.c:502] in winex11 > (0x04b8f2d8) > 10 0x05936f92 init_opengl+0xfbe(once=0x5993e00, param=0x0(nil), > context=(nil)) [/home/austin/wine-valgrind/dlls/winex11.drv/opengl.c:679] in > winex11 (0x04b8f4e8) > > Important context in the original output is the following: wine: Unhandled illegal instruction at address 0x63bcd77 (thread 0150), starting debugger... Unhandled exception: illegal instruction in 32-bit code (0x063bcd77). ... Backtrace: ... 0x063bcd77: repe I.e., it looks to me like the issue is the repe/repz. Unfortunately I can't tell from that output what instruction repe is supposed to apply to. I imagine a dump of the affected code would be potentially useful, unless this bug report is a duplicate of a known issue.
Created attachment 105934 [details] full bad output
Created attachment 105935 [details] this time, without -march=corei7
Created attachment 105936 [details] swrast_dir32.so
Created attachment 105937 [details] swrast_dir64.so
So, while testing again, I realized I hadn't rerun the test with software rendering (the full valgrind run and individual test runs are two different scripts, and the later wasn't forcing software mode). The previous (good) run was presumably using radeonsi.so, fwiw. I've updated the individual script and reran, the output is slightly different from the original no march run, but still shows a difference between march and no march. What's interesting, is that with software rendering and march enabled, I get symbols for neither LLVM or mesa. With no march and software rendering, I get symbols for LLVM, but not mesa. I tried running objdump -d/-D, but they are too large to attach, even compressed. The compressed .so files are small enough, so I attached both. This was a 32-bit wine build, so it should be the 32-bit driver, but I've attached both for reference. My end goal is to either not get crashes under valgrind + mesa, or to get useful stacktraces. I'm not particularly tied to radeonsi/software rendering.
Created attachment 105947 [details] log with march enabled, using radeonsi
Created attachment 105948 [details] log with march disabled, using radeonsi
Created attachment 105949 [details] radeonsi_dri_32.so Had to use xz, bzip2 was over the limit.
Created attachment 105950 [details] radeonsi_dri_64.so
@Henri, I've attached logs use radeonsi_dri.so instead of swrast (which is what I was using before investigating the issue). This contains the repe instruction as before. I've also attached the library itself (built with march), xz compressed.
The 32 bit x86 pipeline only supports up to and including SSSE3, but nothing after that, apart from a very few SSE4 instructions. This is due to limited developer availability, which means that what effort we do have has gone to improving coverage of the 64 bit x86 pipeline.