Re: Multiple false-positive warnings from Valgrind

On Wed, Mar 29, 2017 at 12:34:52PM +0900, Michael Paquier wrote:
> On Thu, Mar 23, 2017 at 5:15 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > On Tue, Mar 21, 2017 at 10:57 PM, Aleksander Alekseev
> > <a(dot)alekseev(at)postgrespro(dot)ru> wrote:
> >> Recently I've decided to run PostgreSQL under Valgrind according to wiki
> >> description [1]. Lots of warnings are generated [2] but it is my
> >> understanding that all of them are false-positive. For instance I've
> >> found these two reports particularly interesting:
> >>
> >> ```
> >> ==00:00:40:40.161 7677== Use of uninitialised value of size 8
> >> ==00:00:40:40.161 7677== at 0xA15FF5: pg_b64_encode (base64.c:68)
> >> ==00:00:40:40.161 7677== by 0x6FFE85: scram_build_verifier (auth-scram.c:348)
> >> ==00:00:40:40.161 7677== by 0x6F3F76: encrypt_password (crypt.c:171)
> >> ==00:00:40:40.161 7677== by 0x68F40C: CreateRole (user.c:403)
> >> ==00:00:40:40.161 7677== by 0x85D53A: standard_ProcessUtility (utility.c:716)
> >> ==00:00:40:40.161 7677== by 0x85CCC7: ProcessUtility (utility.c:353)
> >> ==00:00:40:40.161 7677== by 0x85BD22: PortalRunUtility (pquery.c:1165)
> >> ==00:00:40:40.161 7677== by 0x85BF20: PortalRunMulti (pquery.c:1308)
> >> ==00:00:40:40.161 7677== by 0x85B4A0: PortalRun (pquery.c:788)
> >> ==00:00:40:40.161 7677== by 0x855672: exec_simple_query (postgres.c:1101)
> >> ==00:00:40:40.161 7677== by 0x8597BB: PostgresMain (postgres.c:4066)
> >> ==00:00:40:40.161 7677== by 0x7C6322: BackendRun (postmaster.c:4317)
> >> ==00:00:40:40.161 7677== Uninitialised value was created by a stack allocation
> >> ==00:00:40:40.161 7677== at 0x6FFDB7: scram_build_verifier (auth-scram.c:328)
> >
> > I can see those warnings as well after calling a code path of
> > scram_build_verifier(), and I have a hard time seeing that as nothing
> > else than a false positive as you do. All those warnings go away if
> > you just initialize just do MemSet(salt, 0, SCRAM_SALT_LEN) before
> > calling pg_backend_random() but this data is filled in with
> > RAND_bytes() afterwards (if built with openssl). The estimated lengths
> > of the encoding are also correct. I don't see immediately what's wrong
> > here, this deserves a second look...
>
> And it seems to me that this is caused by the routines of OpenSSL.
> When building without --with-openssl, using the fallback
> implementations of SHA256 and RAND_bytes I see no warnings generated
> by scram_build_verifier... I think it makes most sense to discard that
> from the list of open items.

This defect has roughly the gravity of a compiler warning. Dropped from open
items on that basis.