I need some help with running valgrind under wine. I'm debuging a mesa issue (see: https://gitlab.freedesktop.org/mesa/mes ... ests/14883 and https://gitlab.freedesktop.org/mesa/mesa/-/issues/5971 for more details) which ultimately leads to invalid free:
Code: Select all
$ wine apitrace.exe replay d3d9.trace1
Z:\home\clemens\Downloads\Cxbx\2019\cxbxr-ldr.exe
DRI3 backend not active (slower performance)
nine:adapter9:ctor: Your card is at the limit of Gallium Nine requirements. Some games may run into issues because requirements are too tight
Native Direct3D 9 v0.8.0.385-release is active.
For more information visit https://github.com/iXit/wine-nine-standalone
0150:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFA, 0128FF08
0158:fixme:imm:ImeSetActiveContext (0x28e250, 1): stub
0158:fixme:imm:ImmReleaseContext (00020074, 0028E250): stub
fixme:d3d9nine:DRIPresentGroup_GetMultiheadCount (0x28dca8), stub!
fixme:d3d9nine:DRIPresentGroup_GetMultiheadCount (0x28dca8), stub!
free(): invalid next size (fast)
350: debug: apitrace: warning: caught exception 0x80000101
apitrace: warning: caught exception 0x80000101
350: error: caught an unhandled exception
malloc(): invalid size (unsorted)
350: debug: apitrace: warning: caught exception 0x80000101
apitrace: warning: caught exception 0x80000101
350: error: caught an unhandled exception
0150:err:seh:NtRaiseException Unhandled exception code 40 flags b7e3f7e3 addr 0x12aeae0
013c:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFA, 0021FEBC
Code: Select all
$ valgrind --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access --error-limit=no wine apitrace.exe replay d3d9.trace1
.......
vex x86->IR: unhandled instruction bytes: 0xF2 0x75 0x2 0xF2
==19899== valgrind: Unrecognised instruction at address 0x4b4e09.
==19899== at 0x4B4E09: ???
==19899== by 0x7BC76578: call_exception_handler (in /home/paulie/wine-7.0/dlls/ntdll/ntdll.dll.so)
==19899== by 0x7BC7654A: EXC_CallHandler (in /home/paulie/wine-7.0/dlls/ntdll/ntdll.dll.so)
==19899== by 0x7BC76EBC: call_stack_handlers (signal_i386.c:140)
==19899== by 0x7BC76EBC: dispatch_exception (signal_i386.c:225)
==19899== by 0x7BC763DC: KiUserExceptionDispatcher (in /home/paulie/wine-7.0/dlls/ntdll/ntdll.dll.so)
==19899== by 0x7F10FEAF: ???
==19899== by 0x7B64CE3F: __fastcall_BaseThreadInitThunk (in /home/paulie/wine-7.0/dlls/kernel32/kernel32.dll.so)
==19899== by 0x7BC7B4A6: call_thread_func_wrapper (in /home/paulie/wine-7.0/dlls/ntdll/ntdll.dll.so)
==19899== by 0x7BC7BAF9: call_thread_func (thread.c:225)
==19899== Your program just tried to execute an instruction that Valgrind
==19899== did not recognise. There are two possible reasons for this.
==19899== 1. Your program has a bug and erroneously jumped to a non-code
==19899== location. If you are running Memcheck and you just saw a
==19899== warning about a bad jump, it's probably your program's fault.
==19899== 2. The instruction is legitimate but Valgrind doesn't handle it,
==19899== i.e. it's Valgrind's fault. If you think this is the case or
==19899== you are not sure, please let us know and we'll try to fix it.
==19899== Either way, Valgrind will now raise a SIGILL signal which will
==19899== probably kill your program.
0160:err:seh:segv_handler Got unexpected trap 0
BTW this is with gallium-nine, but I'm quite sure that doesn't matter here, the problems I was looking at are shader related and it just happens that nine generates shader code that ultimately hits the problematic path.
