Re: RISC-V animals sporadically produce weird memory-related failures

Hello Tom,

17.11.2024 20:28, Tom Turelinckx wrote:
> I have now done just that, but on a new HiFive Premier P550 board [2]. It is running Ubuntu 24.04 LTS with a board-specific kernel, currently 6.6.21-9-premier (2024-11-09). The buildfarm client is executing within a Debian Trixie container created from the official Debian repo.
>
> This stack is a lot more recent, should be more future-proof, and the board is significantly faster too. Boomslang has already built all branches and copperhead is currently going through them.

Thank you for upgrading these machines!

Could you please take a look at new failures produced by copperhead
recently?:
[1]
2024-11-30 19:34:53.302 CET [13395:4] LOG:  server process (PID 13439) was terminated by signal 11: Segmentation fault
2024-11-30 19:34:53.302 CET [13395:5] DETAIL:  Failed process was running: SELECT '' AS tf_12, BOOLTBL1.*, BOOLTBL2.*
       FROM BOOLTBL1, BOOLTBL2
       WHERE BOOLTBL2.f1 <> BOOLTBL1.f1;

[2]
2024-11-30 19:54:11.478 CET [27560:15] LOG:  server process (PID 28459) was terminated by signal 11: Segmentation fault
2024-11-30 19:54:11.478 CET [27560:16] DETAIL:  Failed process was running: SELECT count(*) FROM test_tsvector WHERE a
@@ any ('{wr,qh}');

These crashes are hardly related to code changes, so maybe there are
platform-specific issues still...
I've run 100 iterations of `make check` for REL_13_STABLE, using
trixie/sid 6.8.12-riscv64 (gcc 14.2.0), emulated with qemu-system-riscv64,
with no failures.

Unfortunately, the log files saved don't include coredump information,
maybe because of inappropriate core_pattern.
(Previously, a stack trace was extracted in case of a crash: [3].)

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=copperhead&dt=2024-11-30%2018%3A16%3A37
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=copperhead&dt=2024-11-30%2018%3A35%3A17
[3] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=copperhead&dt=2024-09-03%2016%3A38%3A46

Best regards,
Alexander