On Tue, 2010-10-12 at 22:30 +0100, David Woodhouse wrote:
> However, it doesn't quite work as I want -- the 'superblocks' used by
> the slab allocator are allocated with memalign, so they are tracked by
> valgrind already. And thus although I seem to mostly get the right
> warnings at the right times, the allocation stack trace is the wrong
> one. For example, this test case:
>
> foo = g_slice_alloc(20);
> foo[20] = 0;
> g_slice_free1(20, foo);
> foo = g_slice_alloc(20);
> g_free(foo);
>
> ...gives this output:
...
> ==18242== Address 0x4f38020 is 32 bytes inside a block of size 496 alloc'd
> ==18242== at 0x4A04360: memalign (vg_replace_malloc.c:532)
...
> How can I make Valgrind *forget* that the slab allocator's superblock
> was originally allocated with memalign?
I tried making it allocate its superblocks using anonymous mmap, which
fixes that. But still the reports are incorrect -- this test code:
foo = g_slice_alloc(20);
foo[19] = 0;
foo[20] = 0;
g_slice_free1(20, foo);
g_slice_free1(20, foo);
foo = g_slice_alloc(20);
g_free(foo);
... gives this output.
client request: code 1305, addr 0x4F10900, len 82907136
==21187== mempool_alloc(0x4f10900, 0x4f11000, 20)
==21187== at 0x4C69652: g_slice_alloc (gslice.c:841)
==21187== by 0x4005B5: main (slice.c:7)
==21187== Invalid write of size 1
==21187== at 0x4005CD: main (slice.c:9)
==21187== Address 0x4f11014 is not stack'd, malloc'd or (recently) free'd
==21187==
client request: code 1306, addr 0x4F10900, len 82907136
==21187== mempool_free(0x4f10900, 0x4f11000)
==21187== at 0x4C6A04D: g_slice_free1 (gslice.c:903)
==21187== by 0x4005E0: main (slice.c:10)
==21187== mempool_free(0x4f10900, 0x4f11000) freed chunk of 20 bytes
client request: code 4d430001, addr 0x4F11000, len 16
client request: code 1306, addr 0x4F10900, len 82907136
==21187== mempool_free(0x4f10900, 0x4f11000)
==21187== at 0x4C6A04D: g_slice_free1 (gslice.c:903)
==21187== by 0x4005F1: main (slice.c:11)
==21187== Invalid free() / delete / delete[]
==21187== at 0x4C6A04D: g_slice_free1 (gslice.c:903)
==21187== by 0x4005F1: main (slice.c:11)
==21187== Address 0x4f11000 is not stack'd, malloc'd or (recently) free'd
==21187==
client request: code 4d430001, addr 0x4F11000, len 16
client request: code 4d430000, addr 0x4F11020, len 32
client request: code 1305, addr 0x4F10900, len 82907168
==21187== mempool_alloc(0x4f10900, 0x4f11020, 20)
==21187== at 0x4C69652: g_slice_alloc (gslice.c:841)
==21187== by 0x4005FB: main (slice.c:12)
--21187-- REDIR: 0x3197c7cdb0 (free) redirected to 0x4a04ceb (free)
==21187== Invalid free() / delete / delete[]
==21187== at 0x4A04D72: free (vg_replace_malloc.c:325)
==21187== by 0x400610: main (slice.c:13)
==21187== Address 0x4f11020 is not stack'd, malloc'd or (recently) free'd
==21187==
It's telling me that 0x4f11000 is not recently freed, about 9 lines
after it prints the message saying it was freed! WTF?
This is Valgrind 3.5.0 on Fedora 14 x86_64.
--
dwmw2
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
