Re: RISC-V animals sporadically produce weird memory-related failures - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: RISC-V animals sporadically produce weird memory-related failures
Date
Msg-id 94fa5817-7934-f8f5-1ae2-699080fc3251@gmail.com
Whole thread Raw
In response to Re: RISC-V animals sporadically produce weird memory-related failures  ("Tom Turelinckx" <pgbf@twiska.com>)
Responses Re: RISC-V animals sporadically produce weird memory-related failures
List pgsql-hackers
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-specifickernel, currently 6.6.21-9-premier (2024-11-09). The buildfarm client is executing within a Debian Trixie
containercreated 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
hasalready 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



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Re: Added prosupport function for estimating numeric generate_series rows
Next
From: Kirill Reshke
Date:
Subject: Re: Using read stream in autoprewarm