| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Amul Sul <sulamul(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: new heapcheck contrib module |
| Date: | 2020-10-22 20:49:16 |
| Message-ID: | 42432.1603399756@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
>> On Oct 22, 2020, at 1:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-10-22 21:06:19 | Re: new heapcheck contrib module |
| Previous Message | Mark Dilger | 2020-10-22 20:39:15 | Re: new heapcheck contrib module |