In message <20220530231819.26e3...@slippy.cwsent.com>, Cy Schubert writes: > In message <ypvpetkzskbpw...@albert.catwhisker.org>, David Wolfskill writes: > > > > > > --fbDsVP+DlYRwzumm > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, May 30, 2022 at 03:53:29PM -0700, Cy Schubert wrote: > > > ... > > > I don't think this is a filesystem problem. All my / filesystems trace=20 > > > their ancestry back to the same machine decades ago. All were cloned at o > = > > ne=20 > > > point using dump | restore. All were newfs'd at some point to update from > = > > =20 > > > 8K blocks to 16K and eventually 32K blocksize, either using my USB rescue > = > > =20 > > > disk or a little bit of geom_mirror musical chairs. All four machines are > = > > =20 > > > consistently set up the same as each other (as much as possible consideri > = > > ng=20 > > > different hardware and mirrors, except for the laptop which has a single= > > =20 > > > disk). > > > > I'm not disagreeing with you. :-) > > > > Providing the FS image (to Toomas) was a diagnostic aid: using it, he > > was able to reproduce the issue in his test-scaffolding environment, and > > was having some "quality time with gdb" before he needed to do other > > things (probably involving sleep). > > Hmmm. How interesting. > > Even after having newfs'd the filesystem and restoring it using a kernel > and userland that did not have the commit in question I still had the > problem.
The two malloc()s are ok. The problem could be filesystem related. -- Cheers, Cy Schubert <cy.schub...@komquats.com> or <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e**(i*pi)+1=0
