Subject: Re: Make mesage at end-of-recovery less scary.

From: Kyotaro Horiguchi <[email-masked]>
Date: Tue, 29 Mar 2022 15:07:01 +0900 (JST)

me> Rebased to the current HEAD.

b64c3bd62e (removal of unused "use Config") conflicted on a TAP
script.

Rebased.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

---

From: Jacob Champion <[email-masked]>
Date: Wed, 6 Jul 2022 11:05:51 -0700

> Rebased.

Unfortunately this will need another rebase over latest.

[CFM hat] Looking through the history here, this has been bumped to
Ready for Committer a few times and then bumped back to Needs Review
after a required rebase. What's the best way for us to provide support
for contributors who get stuck in this loop? Maybe we can be more
aggressive about automated notifications when a RfC patch goes red in
the cfbot?

Thanks,
--Jacob

---

From: Michael Paquier <[email-masked]>
Date: Thu, 7 Jul 2022 09:04:07 +0900

> aggressive about automated notifications when a RfC patch goes red in

Having a better integration between the CF bot and the CF app would be
great, IMO.  People tend to easily forget about what they send in my
experience, even if they manage a small pool of patches or a larger
one.
--
Michael

---

From: Kyotaro Horiguchi <[email-masked]>
Date: Thu, 07 Jul 2022 17:32:33 +0900 (JST)

At Wed, 6 Jul 2022 11:05:51 -0700, Jacob Champion <[email-masked]> wrote in 
> Unfortunately this will need another rebase over latest.

Thanks! Done. 

regards.

---

From: Justin Pryzby <[email-masked]>
Date: Fri, 16 Sep 2022 23:21:50 -0500

@cfbot: rebased over adb466150, which did the same thing as one of the
hunks in xlogreader.c.

---

From: Kyotaro Horiguchi <[email-masked]>
Date: Mon, 26 Sep 2022 16:17:37 +0900 (JST)

At Fri, 16 Sep 2022 23:21:50 -0500, Justin Pryzby <[email-masked]> wrote in 
> @cfbot: rebased over adb466150, which did the same thing as one of the

Oops. Thanks! And then this gets a further conflict (param names
harmonization). So further rebased.  And removed an extra blank line
you pointed.

regards.

---

From: Justin Pryzby <[email-masked]>
Date: Thu, 27 Oct 2022 21:37:05 -0500

rebased

---

From: Kyotaro Horiguchi <[email-masked]>
Date: Fri, 18 Nov 2022 17:25:37 +0900 (JST)

Just rebased.

regards.

---

From: Andres Freund <[email-masked]>
Date: Tue, 22 Nov 2022 09:20:27 -0800

Hi,

> Just rebased.

Fails with address sanitizer:
https://cirrus-ci.com/task/5632986241564672

Unfortunately one of the failures is in pg_waldump and we don't seem to
capture its output in 011_crash_recovery. So we don't see the nice formattted
output...

[11:07:18.868] #0  0x00007fcf43803ce1 in raise () from /lib/x86_64-linux-gnu/libc.so.6
[11:07:18.912] 
[11:07:18.912] Thread 1 (Thread 0x7fcf43662780 (LWP 39124)):
[11:07:18.912] #0  0x00007fcf43803ce1 in raise () from /lib/x86_64-linux-gnu/libc.so.6
[11:07:18.912] No symbol table info available.
[11:07:18.912] #1  0x00007fcf437ed537 in abort () from /lib/x86_64-linux-gnu/libc.so.6
[11:07:18.912] No symbol table info available.
[11:07:18.912] #2  0x00007fcf43b8511b in __sanitizer::Abort () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:155
[11:07:18.912] No locals.
[11:07:18.912] #3  0x00007fcf43b8fce8 in __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:58
[11:07:18.912] No locals.
[11:07:18.912] #4  0x00007fcf43b7244c in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7ffd4fde18e6, __in_chrg=<optimized out>) at ../../../../src/libsanitizer/asan/asan_report.cpp:186
[11:07:18.912]         buffer_copy = {<__sanitizer::InternalMmapVectorNoCtor<char>> = {data_ = 0x7fcf40350000 '=' <repeats 65 times>, "\n==39124==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x625000002100 at pc 0x55c36c21e315 bp 0x7ffd4fde2550 sp 0x7ffd4fde2"..., capacity_bytes_ = 65536, size_ = <optimized out>}, <No data fields>}
...
[11:07:18.912] #6  0x00007fcf43b72788 in __asan::__asan_report_load1 (addr=<optimized out>) at ../../../../src/libsanitizer/asan/asan_rtl.cpp:117
[11:07:18.912]         bp = 140725943412048
[11:07:18.912]         pc = <optimized out>
[11:07:18.912]         local_stack = 140528180793728
[11:07:18.912]         sp = 140725943412040
[11:07:18.912] #7  0x000055c36c21e315 in ValidXLogRecordLength (state=state@entry=0x61a000000680, RecPtr=RecPtr@entry=33655480, record=record@entry=0x625000000bb8) at xlogreader.c:1126
[11:07:18.912]         p = <optimized out>
[11:07:18.912]         pe = 0x625000002100 ""
[11:07:18.912] #8  0x000055c36c21e3b1 in ValidXLogRecordHeader (state=state@entry=0x61a000000680, RecPtr=RecPtr@entry=33655480, PrevRecPtr=33655104, record=record@entry=0x625000000bb8, randAccess=randAccess@entry=false) at xlogreader.c:1169
[11:07:18.912] No locals.

The  most important bit is "AddressSanitizer: heap-buffer-overflow on address 0x6250000\
02100 at pc 0x55c36c21e315 bp 0x7ffd4fde2550 sp 0x7ffd4fde2"

Greetings,

Andres Freund

---

From: Justin Pryzby <[email-masked]>
Date: Tue, 22 Nov 2022 16:04:56 -0600

On Fri, Nov 18, 2022 at 05:25:37PM +0900, Kyotaro Horiguchi wrote:
> +		while (*p == 0 && p < pe)
> +			p++;

The bug reported by Andres/cfbot/ubsan is here.

Fixed in attached.

I didn't try to patch the test case to output the failing stderr, but
that might be good.

---

From: Kyotaro Horiguchi <[email-masked]>
Date: Wed, 30 Nov 2022 11:56:02 +0900 (JST)

At Tue, 22 Nov 2022 16:04:56 -0600, Justin Pryzby <[email-masked]> wrote in 
> The bug reported by Andres/cfbot/ubsan is here.

Ur..ou..

-		while (*p == 0 && p < pe)
+		while (p < pe && *p == 0)

It was an off-by-one error. Thanks!

> I didn't try to patch the test case to output the failing stderr, but

I have made use of Cluster::wait_for_log(), but still find_in_log() is
there since it is used to check if a message that should not be logged
is not logged.

regards.