Re: pgsql: Avoid valgrind complaint about write() of uninitalized bytes.

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <rhaas(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Avoid valgrind complaint about write() of uninitalized bytes.
Date: 2018-02-21 05:34:26
Message-ID: 20180221053426.gp72lw67yfpzkw7a@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-committerspgsql-hackers

On 2018-02-06 19:25:04 +0000, Robert Haas wrote:
> Avoid valgrind complaint about write() of uninitalized bytes.
>
> LogicalTapeFreeze() may write out its first block when it is dirty but
> not full, and then immediately read the first block back in from its
> BufFile as a BLCKSZ-width block. This can only occur in rare cases
> where very few tuples were written out, which is currently only
> possible with parallel external tuplesorts. To avoid valgrind
> complaints, tell it to treat the tail of logtape.c's buffer as
> defined.
>
> Commit 9da0cc35284bdbe8d442d732963303ff0e0a40bc exposed this problem
> but did not create it. LogicalTapeFreeze() has always tended to write
> out some amount of garbage bytes, but previously never wrote less than
> one block of data in total, so the problem was masked.
>
> Per buildfarm members lousyjack and skink.
>
> Peter Geoghegan, based on a suggestion from Tom Lane and me. Some
> comment revisions by me.

Doesn't appear to have fixed the problem entirely:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-02-20%2017%3A10%3A01

relevant excerpt:
==12452== Syscall param write(buf) points to uninitialised byte(s)
==12452== at 0x4E49C64: write (write.c:26)
==12452== by 0x4BF8BF: FileWrite (fd.c:2017)
==12452== by 0x4C1B69: BufFileDumpBuffer (buffile.c:513)
==12452== by 0x4C1C61: BufFileFlush (buffile.c:657)
==12452== by 0x4C21D6: BufFileRead (buffile.c:561)
==12452== by 0x63ADA8: ltsReadBlock (logtape.c:274)
==12452== by 0x63AEF6: ltsReadFillBuffer (logtape.c:304)
==12452== by 0x63B560: LogicalTapeRewindForRead (logtape.c:771)
==12452== by 0x640567: mergeruns (tuplesort.c:2671)
==12452== by 0x645122: tuplesort_performsort (tuplesort.c:1866)
==12452== by 0x23357D: _bt_parallel_scan_and_sort (nbtsort.c:1626)
==12452== by 0x234F71: _bt_parallel_build_main (nbtsort.c:1527)
==12452== Address 0xc3cd368 is 744 bytes inside a block of size 8,272 client-defined
==12452== at 0x6362D1: palloc (mcxt.c:858)
==12452== by 0x4C1DA6: BufFileCreateShared (buffile.c:249)
==12452== by 0x63B062: LogicalTapeSetCreate (logtape.c:571)
==12452== by 0x64489A: inittapes (tuplesort.c:2419)
==12452== by 0x644B1C: puttuple_common (tuplesort.c:1695)
==12452== by 0x644E01: tuplesort_putindextuplevalues (tuplesort.c:1545)
==12452== by 0x233391: _bt_spool (nbtsort.c:514)
==12452== by 0x2333CA: _bt_build_callback (nbtsort.c:574)
==12452== by 0x286004: IndexBuildHeapRangeScan (index.c:2879)
==12452== by 0x286366: IndexBuildHeapScan (index.c:2419)
==12452== by 0x23356F: _bt_parallel_scan_and_sort (nbtsort.c:1615)
==12452== by 0x234F71: _bt_parallel_build_main (nbtsort.c:1527)
==12452== Uninitialised value was created by a heap allocation
==12452== at 0x6362D1: palloc (mcxt.c:858)
==12452== by 0x63B20E: LogicalTapeWrite (logtape.c:634)
==12452== by 0x63EA46: writetup_index (tuplesort.c:4206)
==12452== by 0x643769: dumptuples (tuplesort.c:2994)
==12452== by 0x64511A: tuplesort_performsort (tuplesort.c:1865)
==12452== by 0x23357D: _bt_parallel_scan_and_sort (nbtsort.c:1626)
==12452== by 0x234F71: _bt_parallel_build_main (nbtsort.c:1527)
==12452== by 0x252E2A: ParallelWorkerMain (parallel.c:1397)
==12452== by 0x4614DF: StartBackgroundWorker (bgworker.c:841)
==12452== by 0x46F400: do_start_bgworker (postmaster.c:5741)
==12452== by 0x46F541: maybe_start_bgworkers (postmaster.c:5954)
==12452== by 0x4700A6: sigusr1_handler (postmaster.c:5134)
==12452==
==12452== VALGRINDERROR-END

Note that the above path doesn't appear to go through
LogicalTapeFreeze(), therfore not hitting the VALGRIND_MAKE_MEM_DEFINED
added in the above commit.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-02-21 07:17:54 Re: Hash Joins vs. Bloom Filters / take 2
Previous Message Andres Freund 2018-02-21 05:26:57 Re: pgsql: Do execGrouping.c via expression eval machinery, take two.

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Geoghegan 2018-02-21 18:55:20 Re: pgsql: Avoid valgrind complaint about write() of uninitalized bytes.
Previous Message Andres Freund 2018-02-21 05:26:57 Re: pgsql: Do execGrouping.c via expression eval machinery, take two.