Re: bug in SlabAlloc / VALGRIND_MAKE_MEM_DEFINED
От | Andres Freund |
---|---|
Тема | Re: bug in SlabAlloc / VALGRIND_MAKE_MEM_DEFINED |
Дата | |
Msg-id | 20170404214628.ep2hesmekjz5jtre@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: bug in SlabAlloc / VALGRIND_MAKE_MEM_DEFINED (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-hackers |
On 2017-04-04 23:23:30 +0200, Tomas Vondra wrote: > On 04/04/2017 10:42 PM, Tomas Vondra wrote: > > Hi, > > > > Andres nagged to me about valgrind runs taking much longer since > > 9fab40ad introduced the SlabContext into reorderbuffer.c. And by > > "longer" I mean hours instead of minutes. > > > > After a bit of investigation I stumbled on this line in slab.c: > > > > VALGRIND_MAKE_MEM_DEFINED(chunk, SlabChunkGetPointer(chunk)); > > > > which is wrong, because the second parameter should be size and not > > another pointer. This essentially marks a lot of memory as defined, > > which results in the extreme test runtime. > > > > Instead, the line should be: > > > > VALGRIND_MAKE_MEM_DEFINED(SlabChunkGetPointer(chunk), sizeof(int32)); > > > > Patch attached. > > > > Turns out SlabCheck() was missing VALGRIND_MAKE_MEM_DEFINED, resulting in a > valgrind failure with --enable-assert. Updated patch version attached, > passing all tests in test_decoding. Pushed, and re-enabled TestDecoding on skink.
В списке pgsql-hackers по дате отправления: