blob: f3d533e4b178616031d847a7fea0bf4a67a53da3 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
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.]
|