Valgrind BBV, Быстрый старт

Страница: 163 / 319

DHAT: a dynamic heap analysis tool
======== SUMMARY STATISTICS ========
guest_insns: 418,901,537
[...]
max-live: 32,512 in 254 blocks
tot-alloc: 32,512 in 254 blocks (avg size 128.00)
deaths: 254, at avg age 300,467,389
acc-ratios: 0.26 rd, 0.20 wr (8,756 b-read, 6,604 b-written)
at 0x4C275B8: malloc (vg_replace_malloc.c:236)
by 0x4C27632: realloc (vg_replace_malloc.c:525)
by 0x56FF41D: QtFontStyle::pixelSize(unsigned short, bool) (qfontdatabase.cpp:269)
by 0x5700D69: loadFontConfig() (qfontdatabase_x11.cpp:1146)
There are two tell-tale signs that this might be a process-lifetime leak. Firstly, the max-live and tot-alloc numbers are
identical. The only way that can happen is if these blocks are all allocated and then all deallocated.
Secondly, the average age at death (300 million insns) is 71% of the total program lifetime (419 million insns), hence
this is not a transient allocation-free spike -- rather, it is spread out over a large part of the entire run. One interpretation
is, roughly, that all 254 blocks were allocated in the first half of the run, held onto for the second half, and then freed
just before exit.
10.2.2. Interpreting the acc-ratios fields
10.2.2.1. A fairly harmless allocation point record
max-live: 49,398 in 808 blocks
tot-alloc: 1,481,940 in 24,240 blocks (avg size 61.13)
deaths: 24,240, at avg age 34,611,026
acc-ratios: 2.13 rd, 0.91 wr (3,166,650 b-read, 1,358,820 b-written)
at 0x4C275B8: malloc (vg_replace_malloc.c:236)
by 0x40350E: tcc_malloc (tinycc.c:6712)
by 0x404580: tok_alloc_new (tinycc.c:7151)
by 0x4046C4: tok_alloc (tinycc.c:7190)
The acc-ratios field tells us that each byte in the blocks allocated here is read an average of 2.13 times before the
block is deallocated. Given that the blocks have an average age at death of 34,611,026, that’s one read per block per
approximately every 15 million instructions. So from that standpoint the blocks aren’t "working" very hard.
More interesting is the write ratio: each byte is written an average of 0.91 times. This tells us that some parts of the
allocated blocks are never written, at least 9% on average. To completely initialise the block would require writing
each byte at least once, and that would give a write ratio of 1.0. The fact that some block areas are evidently unused
might point to data alignment holes or other layout inefficiencies.
Well, at least all the blocks are freed (24,240 allocations, 24,240 deaths).
If all the blocks had been the same size, DHAT would also show the access counts by block offset, so we could see
where exactly these unused areas are.
However, that isn’t the case: the blocks have varying sizes, so DHAT can’t
151