Steps to reproduce: 1. Launch the game 2. Find a new location entrance (e.g. Cassardis gate) 3. Go back and forth between locations a few times, the game will eventually crash with "ERR08 : Memory overrun." (http://i.imgur.com/oPfFvq9.png) Workaround: R600_DEBUG=mono fixes this glxinfo: Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD PITCAIRN (DRM 2.43.0 / 4.4.0-28-lowlatency, LLVM 3.9.0) (0x6818) Version: 12.1.0 Accelerated: yes Video memory: 2048MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.2 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.0
Can you run the game with valgrind --leak-check=full [game command line] and attach the corresponding valgrind output? Please make sure at least radeonsi_dri.so has debugging symbols available for this.
Created attachment 125187 [details] valgrind --leak-check=full --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access --workaround-gcc296-bugs=yes --smc-check=all wine DDDA.exe (In reply to Michel Dänzer from comment #1) > Can you run the game with > > valgrind --leak-check=full [game command line] > > and attach the corresponding valgrind output? > > Please make sure at least radeonsi_dri.so has debugging symbols available > for this. It does not launch under valgrind for me, it dies from unknown instruction in ntdll (log attached) vex x86->IR: unhandled instruction bytes: 0x36 0x89 0x50 0xC Also to clarify, "ERR08 : Memory overrun." refers to GPU's video memory running out, the game does not cause system OOM.
(In reply to kudahkukarek from comment #2) > It does not launch under valgrind for me, it dies from unknown instruction > in ntdll (log attached) > > vex x86->IR: unhandled instruction bytes: 0x36 0x89 0x50 0xC valgrind doesn't understand some (not very) recent AMD specific instructions yet. I build everything with -march=amdfam10 -mtune=native to avoid this. > Also to clarify, "ERR08 : Memory overrun." refers to GPU's video memory > running out, the game does not cause system OOM. Right, but video memory leaks are usually accompanied by corresponding system memory leaks, which can be caught by valgrind.
(In reply to Michel Dänzer from comment #3) > valgrind doesn't understand some (not very) recent AMD specific instructions > yet. I build everything with -march=amdfam10 -mtune=native to avoid this. Ok, I'll recompile wine and try again. > Right, but video memory leaks are usually accompanied by corresponding > system memory leaks, which can be caught by valgrind. True, the game does noticeably leak system memory (1.5+ GiB footprint with precompiled shaders vs 500 MB with mono)
Created attachment 125253 [details] valgrind_output_i686 I rebuilt wine with -march=amdfam10 and still get the same error (log attached), I also tried building with -march=i686 -mtune=generic and running valgrind on wine-1.7.44-gallium-nine binary from playonlinux with the same outcome. I tried both valgrind-3.11 from xenial repo and valgrind-3.12-svn from some random ppa. All other 3d wine games crash as well even if they use OpenGL, though tracing explorer.exe works. (In reply to Michel Dänzer from comment #3) > valgrind doesn't understand some (not very) recent AMD specific instructions > yet. I build everything with -march=amdfam10 -mtune=native to avoid this. AMD-specific or AMD64-specific? Either way, I use an Intel CPU and 32-bit wine. Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz Stepping: 3 CPU MHz: 3900.039 CPU max MHz: 3900,0000 CPU min MHz: 800,0000 BogoMIPS: 6999.79 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 8192K NUMA node0 CPU(s): 0-7 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm ida arat pln pts
(In reply to kudahkukarek from comment #5) > I rebuilt wine with -march=amdfam10 and still get the same error [...] The instruction valgrind doesn't know could be in Mesa or any other library used by Wine. > [...] I use an Intel CPU and 32-bit wine. It's probably an instruction from a recent Intel extension then.
0x36 looks like a segment override (ss segment) prefix (0x89 would be a mov), so nothing new. This looks like a valgrind bug to me: https://bugs.kde.org/show_bug.cgi?id=344139 which seems old, in particular no updates since over a year (and specifically mentions wine is using such segment override prefixes).
(In reply to Roland Scheidegger from comment #7) > 0x36 looks like a segment override (ss segment) prefix (0x89 would be a > mov), so nothing new. > This looks like a valgrind bug to me: > https://bugs.kde.org/show_bug.cgi?id=344139 which seems old, in particular > no updates since over a year (and specifically mentions wine is using such > segment override prefixes). Looks like a fix has been merged into valgringd git.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/123.
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.