Re: new heapcheck contrib module - Mailing list pgsql-hackers

From Tom Lane
Subject Re: new heapcheck contrib module
Date
Msg-id 42432.1603399756@sss.pgh.pa.us
Whole thread Raw
In response to Re: new heapcheck contrib module  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: new heapcheck contrib module
List pgsql-hackers
Mark Dilger <mark.dilger@enterprisedb.com> writes:
>> On Oct 22, 2020, at 1:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm, but why are we seeing the failure only on specific machine
>> architectures?  sparc64 and ppc32 is a weird pairing, too.

> It is seeking to position 32 and writing '\x77\x77\x77\x77'.  x86_64 is
> little-endian, and ppc32 and sparc64 are both big-endian, right?

They are, but that should not meaningfully affect the results of
that corruption step.  You zapped only one line pointer not
several, but it would look the same regardless of endiannness.

I find it more plausible that we might see the bad effects of
the uninitialized variable only on those arches --- but that
theory is still pretty shaky, since you'd think compiler
choices about register or stack-location assignment would
be the controlling factor, and those should be all over the
map.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: new heapcheck contrib module
Next
From: Tom Lane
Date:
Subject: Re: new heapcheck contrib module