Re: [HACKERS] valgrind errors around dsa.c

[Andres Freund]

On 2017-04-08 14:46:04 +1200, Thomas Munro wrote:
> Fix attached.

Thanks. Pushed!

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] valgrind errors around dsa.c

[Thomas Munro]

On Sat, Apr 8, 2017 at 8:57 AM, Thomas Munro
 wrote:
> On Sat, Apr 8, 2017 at 4:49 AM, Andres Freund  wrote:
>> Hi,
>>
>> newly added tests exercise parallel bitmap scans.  And they trigger
>> valgrind errors:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2017-04-07%2007%3A10%3A01
>>
>>
>> ==4567== VALGRINDERROR-BEGIN
>> ==4567== Conditional jump or move depends on uninitialised value(s)
>> ==4567==at 0x5FD62A: check_for_freed_segments (dsa.c:2219)
>> ==4567==by 0x5FD97E: dsa_get_address (dsa.c:934)
>> ==4567==by 0x5FDA2A: init_span (dsa.c:1339)
>> ==4567==by 0x5FE6D1: ensure_active_superblock (dsa.c:1696)
>> ==4567==by 0x5FEBBD: alloc_object (dsa.c:1452)
>> ==4567==by 0x5FEBBD: dsa_allocate_extended (dsa.c:693)
>> ==4567==by 0x3C7A83: pagetable_allocate (tidbitmap.c:1536)
>> ==4567==by 0x3C7A83: pagetable_create (simplehash.h:342)
>> ==4567==by 0x3C7A83: tbm_create_pagetable (tidbitmap.c:323)
>> ==4567==by 0x3C8DAD: tbm_get_pageentry (tidbitmap.c:1246)
>> ==4567==by 0x3C98A1: tbm_add_tuples (tidbitmap.c:432)
>> ==4567==by 0x22510C: btgetbitmap (nbtree.c:460)
>> ==4567==by 0x21A8D1: index_getbitmap (indexam.c:726)
>> ==4567==by 0x38AD48: MultiExecBitmapIndexScan (nodeBitmapIndexscan.c:91)
>> ==4567==by 0x37D353: MultiExecProcNode (execProcnode.c:621)
>> ==4567==  Uninitialised value was created by a heap allocation
>> ==4567==at 0x602FD5: palloc (mcxt.c:872)
>> ==4567==by 0x5FF73B: create_internal (dsa.c:1242)
>> ==4567==by 0x5FF8F5: dsa_create_in_place (dsa.c:473)
>> ==4567==by 0x37CA32: ExecInitParallelPlan (execParallel.c:532)
>> ==4567==by 0x38C324: ExecGather (nodeGather.c:152)
>> ==4567==by 0x37D247: ExecProcNode (execProcnode.c:551)
>> ==4567==by 0x39870F: ExecNestLoop (nodeNestloop.c:156)
>> ==4567==by 0x37D1B7: ExecProcNode (execProcnode.c:512)
>> ==4567==by 0x3849D4: fetch_input_tuple (nodeAgg.c:686)
>> ==4567==by 0x387764: agg_retrieve_direct (nodeAgg.c:2306)
>> ==4567==by 0x387A11: ExecAgg (nodeAgg.c:2117)
>> ==4567==by 0x37D217: ExecProcNode (execProcnode.c:539)
>> ==4567==
>>
>> It could be that these are spurious due to shared memory - valgrind
>> doesn't track definedness across processes - but the fact that memory
>> allocated by palloc is the source of the undefined memory makes me doubt
>> that.
>
> Thanks.  Will post a fix for this later today.

Fix attached.

Explanation:  Whenever segments are destroyed because they no longer
contain any live blocks, the shared variable
control->freed_segment_counter advances.  Each attached backend has
its own local variable area->freed_segment_counter, and if it sees
that the former differs from the latter it checks all attached
segments to see if any need to be detached.  I failed to initialise
the backend-local version, with the consequence that if you were very
unlucky your backend could fail to detach from a no-longer needed
segment until a another segment was eventually freed causing the
shared counter to move again.  More likely, it would notice that they
are different because one holds uninitialised junk, perform a spurious
scan for dead segments, and then get them in sync.

-- 
Thomas Munro
http://www.enterprisedb.com


initialise-freed-segment-counter.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] valgrind errors around dsa.c

[Thomas Munro]

On Sat, Apr 8, 2017 at 4:49 AM, Andres Freund  wrote:
> Hi,
>
> newly added tests exercise parallel bitmap scans.  And they trigger
> valgrind errors:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2017-04-07%2007%3A10%3A01
>
>
> ==4567== VALGRINDERROR-BEGIN
> ==4567== Conditional jump or move depends on uninitialised value(s)
> ==4567==at 0x5FD62A: check_for_freed_segments (dsa.c:2219)
> ==4567==by 0x5FD97E: dsa_get_address (dsa.c:934)
> ==4567==by 0x5FDA2A: init_span (dsa.c:1339)
> ==4567==by 0x5FE6D1: ensure_active_superblock (dsa.c:1696)
> ==4567==by 0x5FEBBD: alloc_object (dsa.c:1452)
> ==4567==by 0x5FEBBD: dsa_allocate_extended (dsa.c:693)
> ==4567==by 0x3C7A83: pagetable_allocate (tidbitmap.c:1536)
> ==4567==by 0x3C7A83: pagetable_create (simplehash.h:342)
> ==4567==by 0x3C7A83: tbm_create_pagetable (tidbitmap.c:323)
> ==4567==by 0x3C8DAD: tbm_get_pageentry (tidbitmap.c:1246)
> ==4567==by 0x3C98A1: tbm_add_tuples (tidbitmap.c:432)
> ==4567==by 0x22510C: btgetbitmap (nbtree.c:460)
> ==4567==by 0x21A8D1: index_getbitmap (indexam.c:726)
> ==4567==by 0x38AD48: MultiExecBitmapIndexScan (nodeBitmapIndexscan.c:91)
> ==4567==by 0x37D353: MultiExecProcNode (execProcnode.c:621)
> ==4567==  Uninitialised value was created by a heap allocation
> ==4567==at 0x602FD5: palloc (mcxt.c:872)
> ==4567==by 0x5FF73B: create_internal (dsa.c:1242)
> ==4567==by 0x5FF8F5: dsa_create_in_place (dsa.c:473)
> ==4567==by 0x37CA32: ExecInitParallelPlan (execParallel.c:532)
> ==4567==by 0x38C324: ExecGather (nodeGather.c:152)
> ==4567==by 0x37D247: ExecProcNode (execProcnode.c:551)
> ==4567==by 0x39870F: ExecNestLoop (nodeNestloop.c:156)
> ==4567==by 0x37D1B7: ExecProcNode (execProcnode.c:512)
> ==4567==by 0x3849D4: fetch_input_tuple (nodeAgg.c:686)
> ==4567==by 0x387764: agg_retrieve_direct (nodeAgg.c:2306)
> ==4567==by 0x387A11: ExecAgg (nodeAgg.c:2117)
> ==4567==by 0x37D217: ExecProcNode (execProcnode.c:539)
> ==4567==
>
> It could be that these are spurious due to shared memory - valgrind
> doesn't track definedness across processes - but the fact that memory
> allocated by palloc is the source of the undefined memory makes me doubt
> that.

Thanks.  Will post a fix for this later today.

-- 
Thomas Munro
http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] valgrind errors around dsa.c

[Andres Freund]

Hi,

newly added tests exercise parallel bitmap scans.  And they trigger
valgrind errors:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2017-04-07%2007%3A10%3A01


==4567== VALGRINDERROR-BEGIN
==4567== Conditional jump or move depends on uninitialised value(s)
==4567==at 0x5FD62A: check_for_freed_segments (dsa.c:2219)
==4567==by 0x5FD97E: dsa_get_address (dsa.c:934)
==4567==by 0x5FDA2A: init_span (dsa.c:1339)
==4567==by 0x5FE6D1: ensure_active_superblock (dsa.c:1696)
==4567==by 0x5FEBBD: alloc_object (dsa.c:1452)
==4567==by 0x5FEBBD: dsa_allocate_extended (dsa.c:693)
==4567==by 0x3C7A83: pagetable_allocate (tidbitmap.c:1536)
==4567==by 0x3C7A83: pagetable_create (simplehash.h:342)
==4567==by 0x3C7A83: tbm_create_pagetable (tidbitmap.c:323)
==4567==by 0x3C8DAD: tbm_get_pageentry (tidbitmap.c:1246)
==4567==by 0x3C98A1: tbm_add_tuples (tidbitmap.c:432)
==4567==by 0x22510C: btgetbitmap (nbtree.c:460)
==4567==by 0x21A8D1: index_getbitmap (indexam.c:726)
==4567==by 0x38AD48: MultiExecBitmapIndexScan (nodeBitmapIndexscan.c:91)
==4567==by 0x37D353: MultiExecProcNode (execProcnode.c:621)
==4567==  Uninitialised value was created by a heap allocation
==4567==at 0x602FD5: palloc (mcxt.c:872)
==4567==by 0x5FF73B: create_internal (dsa.c:1242)
==4567==by 0x5FF8F5: dsa_create_in_place (dsa.c:473)
==4567==by 0x37CA32: ExecInitParallelPlan (execParallel.c:532)
==4567==by 0x38C324: ExecGather (nodeGather.c:152)
==4567==by 0x37D247: ExecProcNode (execProcnode.c:551)
==4567==by 0x39870F: ExecNestLoop (nodeNestloop.c:156)
==4567==by 0x37D1B7: ExecProcNode (execProcnode.c:512)
==4567==by 0x3849D4: fetch_input_tuple (nodeAgg.c:686)
==4567==by 0x387764: agg_retrieve_direct (nodeAgg.c:2306)
==4567==by 0x387A11: ExecAgg (nodeAgg.c:2117)
==4567==by 0x37D217: ExecProcNode (execProcnode.c:539)
==4567==

It could be that these are spurious due to shared memory - valgrind
doesn't track definedness across processes - but the fact that memory
allocated by palloc is the source of the undefined memory makes me doubt
that.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] valgrind errors

[Gregory Stark]

And lest anyone think Teodor and Oleg are the only ones that have that kind of
problem, here are two in resolve_polymorphic_tupdesc that fire several times
in the regression tests:

==20391== Source and destination overlap in strncpy(0x4BD91DA, 0x4BD91DA, 64)
==20391==at 0x4026CC4: strncpy (mc_replace_strmem.c:291)
==20391==by 0x83224CF: namestrcpy (name.c:217)
==20391==by 0x809635F: TupleDescInitEntry (tupdesc.c:463)
==20391==by 0x83B2BA1: resolve_polymorphic_tupdesc (funcapi.c:500)
==20391==by 0x83B272C: internal_get_result_type (funcapi.c:323)
==20391==by 0x83B256B: get_expr_result_type (funcapi.c:234)
==20391==by 0x816DE41: addRangeTableEntryForFunction (parse_relation.c:1138)
==20391==by 0x816023E: transformRangeFunction (parse_clause.c:594)
==20391==by 0x816059A: transformFromClauseItem (parse_clause.c:709)
==20391==by 0x815F686: transformFromClause (parse_clause.c:123)
==20391==by 0x813ADE3: transformSelectStmt (analyze.c:800)
==20391==by 0x8139B83: transformStmt (analyze.c:183)
==20372== Source and destination overlap in strncpy(0x4BD887D, 0x4BD887D, 64)
==20372==at 0x4026CC4: strncpy (mc_replace_strmem.c:291)
==20372==by 0x83224CF: namestrcpy (name.c:217)
==20372==by 0x809635F: TupleDescInitEntry (tupdesc.c:463)
==20372==by 0x83B2BEA: resolve_polymorphic_tupdesc (funcapi.c:507)
==20372==by 0x83B272C: internal_get_result_type (funcapi.c:323)
==20372==by 0x83B256B: get_expr_result_type (funcapi.c:234)
==20372==by 0x816DE41: addRangeTableEntryForFunction (parse_relation.c:1138)
==20372==by 0x816023E: transformRangeFunction (parse_clause.c:594)
==20372==by 0x816059A: transformFromClauseItem (parse_clause.c:709)
==20372==by 0x815F686: transformFromClause (parse_clause.c:123)
==20372==by 0x813ADE3: transformSelectStmt (analyze.c:800)
==20372==by 0x8139B83: transformStmt (analyze.c:183)

I'm not sure if there are any realistic platforms where strcpy with source and
destination exactly equal is really going to cause an actual problem, but...

And another one in tsearch:

==20349== Source and destination overlap in memcpy(0x71ADAE4, 0x71ADAE4, 8)
==20349==at 0x4026B12: memcpy (mc_replace_strmem.c:402)
==20349==by 0x82DC762: dispell_lexize (dict_ispell.c:141)
==20349==by 0x83B0A66: FunctionCall4 (fmgr.c:1360)
==20349==by 0x82D315F: LexizeExec (ts_parse.c:208)
==20349==by 0x82D3776: parsetext (ts_parse.c:399)
==20349==by 0x82E1EBC: to_tsvector_byid (to_tsany.c:226)
==20349==by 0x81E9016: ExecMakeFunctionResult (execQual.c:1665)
==20349==by 0x81E9932: ExecEvalFunc (execQual.c:2097)
==20349==by 0x81ED49F: ExecEvalExprSwitchContext (execQual.c:4076)
==20349==by 0x8276D89: evaluate_expr (clauses.c:3841)
==20349==by 0x82763C0: evaluate_function (clauses.c:3448)
==20349==by 0x8275EA1: simplify_function (clauses.c:3252)

And i think this is just uninitialized data at the end of the bitfield that is
being masked off anyways:

==20253== Conditional jump or move depends on uninitialised value(s)
==20253==at 0x82F2C72: array_bitmap_copy (arrayfuncs.c:3854)
==20253==by 0x82EF4A3: array_set_slice (arrayfuncs.c:2538)
==20253==by 0x81E6B8C: ExecEvalArrayRef (execQual.c:397)
==20253==by 0x81EF8D7: ExecTargetList (execQual.c:4988)
==20253==by 0x81EFDA2: ExecProject (execQual.c:5203)
==20253==by 0x81EFF1F: ExecScan (execScan.c:143)
==20253==by 0x825: ExecSeqScan (nodeSeqscan.c:131)
==20253==by 0x81E5F3C: ExecProcNode (execProcnode.c:363)
==20253==by 0x81E3597: ExecutePlan (execMain.c:1504)
==20253==by 0x81E16F3: standard_ExecutorRun (execMain.c:309)
==20253==by 0x81E15A4: ExecutorRun (execMain.c:258)
==20253==by 0x82CD9E5: ProcessQuery (pquery.c:196)


-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com
  Ask me about EnterpriseDB's PostGIS support!

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] valgrind errors

[Tom Lane]

Neil Conway [EMAIL PROTECTED] writes:
 Any thoughts on what could be causing these errors?

I suspect valgrind is complaining because XLogInsert is memcpy'ing a
struct that has allocation padding in it.  Which of course is a bogus
complaint ...

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] valgrind errors

[Shachar Shemesh]

Tom Lane wrote:

Neil Conway [EMAIL PROTECTED] writes:
 

Any thoughts on what could be causing these errors?
   

I suspect valgrind is complaining because XLogInsert is memcpy'ing a
struct that has allocation padding in it.  Which of course is a bogus
complaint ...
 

As far as I remember (couldn't find modern documentation on the matter) 
Valgrind is resitant to this problem. When a block of memory is copied, 
the initialized/uninitialized status is copied along. It only complains 
when an actual operation is performed using uninitialized memory. This 
was developed for the explicit reason of avoiding the problem you describe.

 Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

Re: [HACKERS] valgrind errors

[Shachar Shemesh]

Shachar Shemesh wrote:

Tom Lane wrote:

I suspect valgrind is complaining because XLogInsert is memcpy'ing a
struct that has allocation padding in it.  Which of course is a bogus
complaint ...
 

As far as I remember (couldn't find modern documentation on the 
matter) Valgrind is resitant to this problem. When a block of memory 
is copied, the initialized/uninitialized status is copied along. It 
only complains when an actual operation is performed using 
uninitialized memory. This was developed for the explicit reason of 
avoiding the problem you describe.

 Shachar

Found it:
http://developer.kde.org/~sewardj/docs-2.0.0/mc_main.html, section 3.3.2
It is important to understand that your program can copy around junk 
(uninitialised) data to its heart's content. Memcheck observes this 
and keeps track of the data, but does not complain. A complaint is 
issued only when your program attempts to make use of uninitialised data.


What IS possible, however, is that there is a bug in one of the 
underlying libraries.

--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [HACKERS] valgrind errors

[Tom Lane]

Neil Conway [EMAIL PROTECTED] writes:
 Valgrind'ing the postmaster yields a fair number of errors. A lot of
 them are similar, such as the following:

 ==29929== Use of uninitialised value of size 4
 ==29929==at 0x80AFB80: XLogInsert (xlog.c:570)

Oh, I see the issue.  Shachar is correct that valgrind doesn't complain
about copying uninitialized bytes.  But it *does* complain about adding
them into a CRC ... so what we are seeing here is gripes about including
padding bytes into a CRC, or writing them out in the case of the
complaints like this one:

 ==29929== Syscall param write(buf) contains uninitialised or
 unaddressable byte(s)

The original pad bytes may be fairly far removed from the point of the
error ... an example is that I was able to make one XLogInsert complaint
go away by changing palloc to palloc0 at tupdesc.c line 413 (in
TupleDescInitEntry), which is several memcpy's removed from the data
that gets passed to XLogInsert.  valgrind's habit of propagating
undef'ness through copies isn't real helpful here.

BTW, valgrind's report about size 4 is actively misleading, because
the only part of that struct that TupleDescInitEntry isn't careful to
set explicitly is a one-byte pad between attislocal and attinhcount.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] valgrind errors

[Shachar Shemesh]

Min Xu (Hsu) wrote:

I am confused by how valgrind define make use of data? Isn't
copy data a type of make use? I mean, if valgrind checks if the
data was used as inputs of memcpy(), it is fine. But if user uses
his own memory_copy(), which loads the data into register,
as if the data is going to be used in some useful computation,
and then copy the register value to some other memory location
to finish the copy (yeah, this IS slow), then valgrind is likely
to be confused too. It may think the data is used.
I guess all I am saying is that valgrind _can_ still make
mistakes about it.
-Min
 

If I understand correctly, a data is defined to be used when anything 
other than copying is done on it. Arithmetic operations, branches, etc. 
will trigger the error. If you copy the data by adding and then 
subtracting a constant from it, valgrind will complain. If all you do 
(as in your example) is copy it around, and then copy it some more, it 
will not.

Yes, it does keep uninitialized bits over your registers. Brrr.

 Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly

Re: [HACKERS] valgrind errors

[Min Xu (Hsu)]

I am also interested in this so I want to make some comments.

On Thu, 22 Apr 2004 Shachar Shemesh wrote :
 Found it:
 http://developer.kde.org/~sewardj/docs-2.0.0/mc_main.html, section 3.3.2
 
 It is important to understand that your program can copy around junk 
 (uninitialised) data to its heart's content. Memcheck observes this 
 and keeps track of the data, but does not complain. A complaint is 
 issued only when your program attempts to make use of uninitialised data.

I am confused by how valgrind define make use of data? Isn't
copy data a type of make use? I mean, if valgrind checks if the
data was used as inputs of memcpy(), it is fine. But if user uses
his own memory_copy(), which loads the data into register,
as if the data is going to be used in some useful computation,
and then copy the register value to some other memory location
to finish the copy (yeah, this IS slow), then valgrind is likely
to be confused too. It may think the data is used.

I guess all I am saying is that valgrind _can_ still make
mistakes about it.

-Min

-- 
We've heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that it is not true.
  --Robert Wilensky

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] valgrind errors

[Tom Lane]

Shachar Shemesh [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 The original pad bytes may be fairly far removed from the point of the
 error ... an example is that I was able to make one XLogInsert complaint
 go away by changing palloc to palloc0 at tupdesc.c line 413 (in
 TupleDescInitEntry), which is several memcpy's removed from the data
 that gets passed to XLogInsert.

 If I understand this correctly, that was a real bug there, wasn't it?

No, just a complete waste of time.  The uninitialized data is just
struct padding, and it matters not what's in there.

To get rid of this class of reports we'd probably have to palloc0 rather
than palloc almost everything, and that strikes me as useless overhead.
It would make more sense to tell valgrind to suppress these particular
events in XLogInsert and XLogFlush.

AFAICS, if we actually had an uninitialized field (rather than
uninitialized padding) it would get detected at the point where the
field is used.  If you run with large enough shared_buffers to avoid
having to discard pages from shmem, I think this would be detected even
across a (nominal) disk write and read.

BTW, there is something in the valgrind manual about adding hints to
teach valgrind about custom alloc/free mechanisms.  Has anyone taught
it about palloc?

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] valgrind errors

[Shachar Shemesh]

Tom Lane wrote:

==29929== Syscall param write(buf) contains uninitialised or
unaddressable byte(s)
   

The original pad bytes may be fairly far removed from the point of the
error ... an example is that I was able to make one XLogInsert complaint
go away by changing palloc to palloc0 at tupdesc.c line 413 (in
TupleDescInitEntry), which is several memcpy's removed from the data
that gets passed to XLogInsert.
Anything asking valgrind to give more stack output might help?

 valgrind's habit of propagating
undef'ness through copies isn't real helpful here.
 

Well, considering the amount of false-positives you would get if you 
didn't...

If I understand this correctly, that was a real bug there, wasn't it?

BTW, valgrind's report about size 4 is actively misleading, because
the only part of that struct that TupleDescInitEntry isn't careful to
set explicitly is a one-byte pad between attislocal and attinhcount.
 

You might want to report that to their bugs list. My browsing the docs 
just now leads me to believe valgrind is, generally, aware that only 
parts of a word can be uninitialized. You can even set it to report it 
at the point where uninitialized and initialized data are merged into a 
single operation.

In fact, that may help with getting the errors closer to the place where 
the actual problem resides. Then again, it may cause it to generate way 
more false positives.

--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] valgrind errors

[Neil Conway]

Valgrind'ing the postmaster yields a fair number of errors. A lot of
them are similar, such as the following:

==29929== Use of uninitialised value of size 4
==29929==at 0x80AFB80: XLogInsert (xlog.c:570)
==29929==by 0x808B0A6: heap_insert (heapam.c:1189)
==29929==by 0x808B19D: simple_heap_insert (heapam.c:1226)
==29929==by 0x80C28CC: AddNewAttributeTuples (heap.c:499)
==29929==by 0x80C2E36: heap_create_with_catalog (heap.c:787)
==29929==by 0x811F5AD: DefineRelation (tablecmds.c:252)
==29929==by 0x81DC9BF: ProcessUtility (utility.c:376)
==29929==by 0x81DB893: PortalRunUtility (pquery.c:780)
==29929==by 0x81DB9CE: PortalRunMulti (pquery.c:844)
==29929==by 0x81DB35C: PortalRun (pquery.c:501)
==29929==by 0x81D75E2: exec_simple_query (postgres.c:935)
==29929==by 0x81D9F95: PostgresMain (postgres.c:2984)
==29929==
==29929== Syscall param write(buf) contains uninitialised or
unaddressable byte(s)
==29929==at 0x3C1BAB28: write (in /usr/lib/debug/libc-2.3.2.so)
==29929==by 0x80B2124: XLogFlush (xlog.c:1416)
==29929==by 0x80AE348: RecordTransactionCommit (xact.c:549)
==29929==by 0x80AE82A: CommitTransaction (xact.c:930)
==29929==by 0x80AED8B: CommitTransactionCommand (xact.c:1242)
==29929==by 0x81D8934: finish_xact_command (postgres.c:1820)
==29929==by 0x81D762C: exec_simple_query (postgres.c:967)
==29929==by 0x81D9F95: PostgresMain (postgres.c:2984)
==29929==by 0x81A524E: BackendRun (postmaster.c:2662)
==29929==by 0x81A489E: BackendStartup (postmaster.c:2295)
==29929==by 0x81A2D0A: ServerLoop (postmaster.c:1165)
==29929==by 0x81A2773: PostmasterMain (postmaster.c:926)
==29929==  Address 0x3C37BB57 is not stack'd, malloc'd or free'd

(These occur hundreds of times while valgrind'ing make installcheck.)
The particular call chain that results in the XLogInsert() error is
variable; for example, here's another error report:

==29937== Use of uninitialised value of size 4
==29937==at 0x80AFA37: XLogInsert (xlog.c:555)
==29937==by 0x80978F3: _bt_split (nbtinsert.c:907)
==29937==by 0x80966A1: _bt_insertonpg (nbtinsert.c:504)
==29937==by 0x8095BB0: _bt_doinsert (nbtinsert.c:141)
==29937==by 0x809CC78: btinsert (nbtree.c:266)
==29937==by 0x826200E: OidFunctionCall6 (fmgr.c:1484)
==29937==by 0x80944FA: index_insert (indexam.c:226)
==29937==by 0x80C79E6: CatalogIndexInsert (indexing.c:121)
==29937==by 0x80C2A0B: AddNewAttributeTuples (heap.c:557)
==29937==by 0x80C2E36: heap_create_with_catalog (heap.c:787)
==29937==by 0x811F5AD: DefineRelation (tablecmds.c:252)
==29937==by 0x81DC9BF: ProcessUtility (utility.c:376)

Any thoughts on what could be causing these errors? (I looked into it,
but couldn't see anything that looked like an obvious culprit.)

-Neil



---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match