Thread: pgsql: ltree: Zero padding bytes when allocating memory for externally

pgsql: ltree: Zero padding bytes when allocating memory for externally

From
Andres Freund
Date:
ltree: Zero padding bytes when allocating memory for externally visible data.

ltree/ltree_gist/ltxtquery's headers stores data at MAXALIGN alignment,
requiring some padding bytes. So far we left these uninitialized. Zero
those by using palloc0.

Author: Andres Freund
Reported-By: Andres Freund / valgrind / buildarm animal skink
Backpatch: 9.1-

Branch
------
REL9_1_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/814570418d5e6bccb766efbe86d27aef206e5511

Modified Files
--------------
contrib/ltree/_ltree_gist.c  | 14 +++++++-------
contrib/ltree/_ltree_op.c    |  8 ++++----
contrib/ltree/ltree_gist.c   | 10 +++++-----
contrib/ltree/ltree_op.c     |  6 +++---
contrib/ltree/ltxtquery_io.c |  2 +-
5 files changed, 20 insertions(+), 20 deletions(-)


Re: pgsql: ltree: Zero padding bytes when allocating memory for externally

From
Andres Freund
Date:
On 2016-03-08 23:13:51 +0000, Andres Freund wrote:
> ltree: Zero padding bytes when allocating memory for externally visible data.

This is marked as the originating commit for a failure on dromedary:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02
the origin of the failure is:
FATAL:  no PostgreSQL user name specified in startup packet
while in the 'comments' tests, which looks fairly independent of this commit.

Tom, did you happen to change config on that machine or anything?

Andres


Andres Freund <andres@anarazel.de> writes:
> On 2016-03-08 23:13:51 +0000, Andres Freund wrote:
>> ltree: Zero padding bytes when allocating memory for externally visible data.

> This is marked as the originating commit for a failure on dromedary:
> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02
> the origin of the failure is:
> FATAL:  no PostgreSQL user name specified in startup packet
> while in the 'comments' tests, which looks fairly independent of this commit.

> Tom, did you happen to change config on that machine or anything?

No, haven't touched it in awhile.  Looks like just a glitch maybe?

            regards, tom lane


I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> This is marked as the originating commit for a failure on dromedary:
>> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02
>> the origin of the failure is:
>> FATAL:  no PostgreSQL user name specified in startup packet
>> while in the 'comments' tests, which looks fairly independent of this commit.

>> Tom, did you happen to change config on that machine or anything?

> No, haven't touched it in awhile.  Looks like just a glitch maybe?

I had a vague feeling that this looked familiar, and it occurred to me
to scan the buildfarm database for occurrences of that error message.
Quite a few hours later, I have these results:

  sysname  |      snapshot       | count
-----------+---------------------+-------
 okapi     | 2012-05-10 06:15:02 |   138
 okapi     | 2012-05-20 00:15:02 |   174
 dromedary | 2014-03-28 00:13:52 |     4
 dromedary | 2014-05-07 06:23:09 |     2
 dromedary | 2016-03-08 23:27:02 |     2

So yeah, we've seen it before, but it sure looks like a system-specific
glitch.  dromedary is a pretty old machine (2006 Mac mini), so I would not
be surprised if it dropped a bit now and then.

            regards, tom lane


Re: pgsql: ltree: Zero padding bytes when allocating memory for externally

From
Andres Freund
Date:
On 2016-03-10 10:57:59 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres@anarazel.de> writes:
> >> This is marked as the originating commit for a failure on dromedary:
> >> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02
> >> the origin of the failure is:
> >> FATAL:  no PostgreSQL user name specified in startup packet
> >> while in the 'comments' tests, which looks fairly independent of this commit.
>
> >> Tom, did you happen to change config on that machine or anything?
>
> > No, haven't touched it in awhile.  Looks like just a glitch maybe?
>
> I had a vague feeling that this looked familiar, and it occurred to me
> to scan the buildfarm database for occurrences of that error message.
> Quite a few hours later, I have these results:

Heh, I tried the same, but limited my search too much timewise; to limit
the cost of the query...

>   sysname  |      snapshot       | count
> -----------+---------------------+-------
>  okapi     | 2012-05-10 06:15:02 |   138
>  okapi     | 2012-05-20 00:15:02 |   174
>  dromedary | 2014-03-28 00:13:52 |     4
>  dromedary | 2014-05-07 06:23:09 |     2
>  dromedary | 2016-03-08 23:27:02 |     2
>
> So yeah, we've seen it before, but it sure looks like a system-specific
> glitch.  dromedary is a pretty old machine (2006 Mac mini), so I would not
> be surprised if it dropped a bit now and then.

dromedary's indeed look rare enough. But okapi had a lot of those. But
I'm also not going to care about failures from 2012...

Thanks for checking!

Andres


Andres Freund <andres@anarazel.de> writes:
> On 2016-03-10 10:57:59 -0500, Tom Lane wrote:
>>  sysname  |      snapshot       | count
>> ----------+---------------------+-------
>> okapi     | 2012-05-10 06:15:02 |   138
>> okapi     | 2012-05-20 00:15:02 |   174
>> dromedary | 2014-03-28 00:13:52 |     4
>> dromedary | 2014-05-07 06:23:09 |     2
>> dromedary | 2016-03-08 23:27:02 |     2
>>
>> So yeah, we've seen it before, but it sure looks like a system-specific
>> glitch.  dromedary is a pretty old machine (2006 Mac mini), so I would not
>> be surprised if it dropped a bit now and then.

> dromedary's indeed look rare enough. But okapi had a lot of those.

But note those were a lot of the same failures in a single buildfarm run.

BTW, this search would have found both the client-side report in
regression.diffs and the postmaster-log report of the same error, so
all of the counts above should be divided by two to identify how many
glitches actually occurred in a given run.

okapi clearly saw some time-extended condition that caused the failure to
occur for most regression-test sessions within a run.  But it hasn't
reappeared since 2012, so my money is on some short-lived kernel bug.
(okapi is running gentoo ... nuf said.)

I don't know what's happening on dromedary, but it's clearly pretty
darn rare.  Given the lack of comparable failures on other Mac buildfarm
members, I'm willing to write it off as a flaky memory bit or some such.

            regards, tom lane