Re: Valgrind Memcheck support

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Valgrind Memcheck support
Дата
Msg-id 20130609215849.GA5554@awork2.anarazel.de
обсуждение исходный текст
Ответ на Valgrind Memcheck support  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On 2013-06-09 17:25:59 -0400, Noah Misch wrote:
> Valgrind's Memcheck tool[1] is handy for finding bugs, but our use of a custom
> allocator limits its ability to detect problems in unmodified PostgreSQL.
> During the 9.1 beta cycle, I found some bugs[2] with a rough patch adding
> instrumentation to aset.c and mcxt.c such that Memcheck understood our
> allocator.  I've passed that patch around to a few people over time, and I've
> now removed the roughness such that it's ready for upstream.  In hopes of
> making things clearer in the commit history, I've split out a preliminary
> refactoring patch from the main patch and attached each separately.

> Besides the aset.c/mcxt.c instrumentation, this patch adds explicit checks for
> undefined memory to PageAddItem() and printtup(); this has caught C-language
> functions that fabricate a Datum without initializing all bits.  The inclusion
> of all this is controlled by a pg_config_manual.h setting.  The patch also
> adds a "suppression file" that directs Valgrind to silences nominal errors we
> don't plan to fix.

Very nice work. I've started to do this quite some time back to smoke
out some bugs in code of mine, but never got remotely to a point where
it was submittable. But I already found some bugs with it. So I'd very
happy if this could get committed.

Will take a look.

> I strongly advise installing the latest-available Valgrind, particularly
> because recent releases suffer far less of a performance drop processing the
> instrumentation added by this patch.  A "make installcheck" run takes 273
> minutes under Vaglrind 3.6.0 but just 27 minutes under Valgrind 3.8.1.

At least on linux amd64 I'd strongly suggest using something newer than
(afair) 3.8.1, i.e. the svn version. Up to that version it corrupts the
stack alignment inside signal handlers which doesn't get fixed up even
after a fork(). This leads to mysterious segfaults, e.g. during elog()s
due to the usage of sse registers which have stronger alignment
requirements.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: 9.3 crop of memory errors
Следующее
От: "MauMau"
Дата:
Сообщение: Re: Hard limit on WAL space used (because PANIC sucks)