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

02.12.2024 18:25, Tom Turelinckx wrote:
>> These crashes are hardly related to code changes, so maybe there are
>> platform-specific issues still...
> I naively assumed that because llvm and clang are available in Trixie on riscv64 that I could simply install them and enable --with-llvm on copperhead, but I then discovered that this caused lots of segmentation faults and I had to revert the --with-llvm again. Sorry about not first testing without submitting results.

Thank you for the clarification!
I hadn't noticed the "--with-llvm" option added in the configuration...
Now I've re-run `make check` for a llvm-enabled build (made with clang
19.1.4) locally and got the same:
2024-12-02 16:49:47.620 UTC postmaster[21895] LOG:  server process (PID 21933) was terminated by signal 11: Segmentation
fault
2024-12-02 16:49:47.620 UTC postmaster[21895] DETAIL:  Failed process was running: SELECT '' AS tf_12, BOOLTBL1.*,
BOOLTBL2.*
           FROM BOOLTBL1, BOOLTBL2
           WHERE BOOLTBL2.f1 <> BOOLTBL1.f1;

A build made with clang-19 without llvm passed `make check` successfully.

> I had increased the core file size limit in /etc/security/limits.conf, but in Trixie this is overruled by a default /etc/security/limits.d/10-coredump-debian.conf. Moreover, the core_pattern was set by apport on the Ubuntu lxc host, but apport is not available in the Trixie lxc guest. I have now corrected both issues, and a simple test resulted in a core file being written to the current directory, like it was before the upgrade.

Thank you for fixing this!

Best regards,
Alexander