1 files changed, 50 insertions, 0 deletions
diff --git a/results/classifier/118/none/1860610 b/results/classifier/118/none/1860610
new file mode 100644
index 000000000..f3d533e4b
--- /dev/null
+++ b/results/classifier/118/none/1860610
@@ -0,0 +1,50 @@
+graphic: 0.334
+semantic: 0.270
+user-level: 0.203
+performance: 0.179
+device: 0.171
+ppc: 0.166
+architecture: 0.158
+i386: 0.147
+x86: 0.147
+risc-v: 0.141
+kernel: 0.137
+socket: 0.134
+network: 0.115
+debug: 0.108
+mistranslation: 0.108
+vnc: 0.096
+virtual: 0.091
+assembly: 0.076
+hypervisor: 0.053
+arm: 0.051
+boot: 0.050
+PID: 0.048
+register: 0.045
+VMM: 0.036
+peripherals: 0.036
+TCG: 0.033
+permissions: 0.032
+KVM: 0.031
+files: 0.013
+
+cap_disas_plugin leaks memory
+
+Looking at origin/master head, the function cap_disas_plugin leaks memory.
+
+per capstone's examples using their ABI, cs_free(insn, count); needs to called just before cs_close.
+
+I discovered this running qemu under valgrind.
+
+It looks like this will fail on all the other capstone cases as well. Is this an API change across versions?
+
+I run git blame in the capstone repository, and cs_free has been around for at least 4 years in the capstone ABI. I can not tell if the need to call cs_free is a (new) requirement. Documentation capstone is a little informal...
+
+What command line where you using? I've been unable to replicate the valgrind warning with a riscv64-linux-user run of hello with the libhowvec.so plugin. Valgrind does complain about a bunch of other stuff though.
+
+Looking at the way disas is structured it seems cap_insn is allocated once (per thread) and re-used for each disassembly so we shouldn't be free'ing it after each usage. In fact the comments to cap_disas_start imply we want to do better than re-initialising the library for every set of instructions we disassemble.
+
+It is true that we don't clean-up any of the disassembly machinery on exit but the same can be said for a lot of QEMU's static state. So currently I don't see a leak rather than a one-time allocation. Unless I can reproduce the leak I'm going to mark this as incomplete for now. 
+
+[Expired for QEMU because there has been no activity for 60 days.]
+