Re: new heapcheck contrib module

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-23 02:01:25
Message-ID: 114862.1603418485@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:
> Ahh, crud. It's because
> syswrite($fh, '\x77\x77\x77\x77', 500)
> is wrong twice. The 500 was wrong, but the string there isn't the bit pattern we want -- it's just a string literal with backslashes and such. It should have been double-quoted.

Argh. So we really have, using same test except

memcpy(&lp, "\\x77", sizeof(lp));

little endian: off = 785c, flags = 2, len = 1b9b
big endian: off = 2e3c, flags = 0, len = 3737

which explains the apparent LP_DEAD result.

I'm not particularly on board with your suggestion of "well, if it works
sometimes then it's okay". Then we have no idea of what we really tested.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-10-23 02:05:34 Re: Would it be helpful for share the patch merge result from cfbot
Previous Message Andy Fan 2020-10-23 02:01:14 Re: Would it be helpful for share the patch merge result from cfbot