On Mon, Apr 14, 2025 at 04:47:47PM +0200, Bruno Haible wrote: > > > System information (uname -a): OpenBSD 7.0 GENERIC#2
> > Bruno will probably be able to fix this in gnulib, and I'll be sure to > > pick up a newer version of gnulib before cutting 1.4.20. > > These failures don't occur in OpenBSD 7.5 and 7.6. > > If OpenBSD 7.0 was still maintained, I would fix these test failures in > gnulib. But the support policy of OpenBSD is that only the last 2 releases > are supported, and since they have a release frequency of 2 / year, > OpenBSD 7.0 is end-of-life already for 2.5 years (since Oct 2022). See > https://en.wikipedia.org/wiki/OpenBSD#Releases . That's useful to know. So, even after I update to newer gnulib (there are other platforms that will benefit), you are likely to still see the coredumps for those gnulib tests on your older platform in the next m4 release, but they should not impact the behavior of your just-built m4. > > > > ------------------------------------------------------------ > > > Note: there is also a third core file: test-c-stack.core > > > > Hmm - so you're stating that running the testsuite created a core file > > but passed? That's worth some investigation as well. Do you have > > libsigsegv installed on the platform, or not, as that may impact how > > gnulib's test-c-stack behaves. > > I reproduce this core dump as well. But that's OK: The test-c-stack.sh > test merely verifies that before m4 exits, it prints "stack overflow". Do we want to try and make test-c-stack.sh a bit smarter to avoid core dumps on more platforms, when we are gracefully handling an intentional stack overflow? Or at a minimum try to clean up any core files that may be created as a side effect of the test running successfully? I'm not too terribly worried by the core dump; most m4 users don't intentionally provoke stack overflow, and the fact that we gracefully detected it is good whether or not a core dump remains as a side effect. But it does seem a bit odd that only some systems are penalized by the higher disk usage due to the core files after a stack overflow. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
