Re: [HACKERS] valgrind errors around dsa.c

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

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: >>

Re: [HACKERS] valgrind errors around dsa.c

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 >

[HACKERS] valgrind errors around dsa.c

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

[HACKERS] valgrind errors

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

Re: [HACKERS] valgrind errors

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

Re: [HACKERS] valgrind errors

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

Re: [HACKERS] valgrind errors

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

Re: [HACKERS] valgrind errors

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

Re: [HACKERS] valgrind errors

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

Re: [HACKERS] valgrind errors

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

Re: [HACKERS] valgrind errors

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

Re: [HACKERS] valgrind errors

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

[HACKERS] valgrind errors

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: