Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)
Date
Msg-id CAH2-WzmK6pgrFcfkxV-xOE8R887_c-qk433FNcWL3beC1RczmA@mail.gmail.com
Whole thread Raw
In response to Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Mar 14, 2022 at 12:15 PM Robert Haas <robertmhaas@gmail.com> wrote:
> If surgery does happen in the future, I would argue that this
> change could easily *mask* bugs, because if somebody tries to apply
> valgrind to this code the useless initializations will just cover up
> what valgrind would otherwise detect as an access to uninitialized
> memory.

I agree. I have found it useful to VALGRIND_MAKE_MEM_DEFINED() a
buffer that would otherwise be considered initialized by Valgrind --
sometimes it's useful to make Valgrind understand that an area of
memory is garbage for all practical purposes. In other words,
sometimes it's useful to go out of your way to work around the problem
of meaningless initialization masking bugs (bugs that could otherwise
be detected by Valgrind).

Of course it's also possible that initializing memory to some
nominally safe value (e.g. using palloc0() rather than palloc()) makes
sense as a defensive measure. It depends on the specific code, of
course.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)
Next
From: Tom Lane
Date:
Subject: Re: generic plans and "initial" pruning