While searching for corefiles recently, I found some from release-20251127 and pre-release testing.
I wonder if it’s related to one of these two?
commit fcdb3229a31dd4ff700c69238814e326aad49098
Author: Toomas Soome <tsoome@me.com>
Date: Thu Dec 12 00:55:19 2024 +0200
17568 remove -Wno-unknown-pragmas
commit 33efde4275d24731ef87927237b0ffb0630b6b2d
Author: Toomas Soome <tsoome@me.com>
Date: Thu Sep 28 10:05:39 2023 +0300
16891 fix unused label and drop -Wno-unused-labelBut it isn’t strictly a problem with the released bits, per se. Disassembly testing between 20251113 and 20251127 proves this.
Dan McDonald commented on 2025-12-02T13:15:01.391-0500 (edited 2025-12-02T13:19:33.563-0500):
I reverted a NUC to 20251113 and I still see corefiles being generated.
Worse still → it appears that the corefiles I see came from a build of source earlier than even 20251113 (commit 26ea1fdbeeebcbe903a632767677c8a6c7ea31d0 was the local illumos tip).
I had not seen corefiles from this until fairly recently. I will look at our Jenkins agents to see if there are corefiles there. Perhaps it is a combination of host and version-of-illumos being built.
Dan McDonald commented on 2025-12-03T10:39:03.711-0500:
Testing note:
An illumos-extra with the patch in it will no longer dump core, and it will also pass configure’s feature test.
The bug is with coreutils' configure. It may get better with an update, if we choose to take 9.9. Since we only use stat, readlink, and seq from coreutils, we don’t care about memset_s at all.
Dan McDonald commented on 2025-12-03T13:39:43.490-0500:
One more thing, this only seems to manifest with gcc10 builds. gcc14 builds do NOT have memset_s tests in configure generate core dumps. This is because gcc14 will not compile the configure memset_s feature test utters.