Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
- Reply: Dimitry Andric : "Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]"
- In reply to: Mark Millard : "Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 26 Nov 2024 10:19:52 UTC
Mark Millard <marklmi@yahoo.com> writes: > From inside a bulk -i where I did a manual make command > after it built and installed libsass.so.1.0.0 . The > manual make produced a /wrkdirs/ : > [...] > So the original creation looks okay. But . . . > [...] > So: The later, staged copy is a bad copy. Both are in the > tmpfs. So copying to the staging area makes a corrupted > copy inside the same tmpfs. After that, further copies of > staging's bad copy can be expected to be messed up. This and the fact that it happens on 14 and 15 but not on 13 strongly suggests an issue wth `copy_file_range(2)`, since `install(1)` in 14 and 15 (but not in 13) now uses `copy_file_range(2)` if at all possible. My educated guess is that hole detection doesn't work reliably for files that have had holes filled while memory-mapped, so `copy_file_range(2)` thinks there is a hole where there isn't one and skips some of the data when `install(1)` uses it to copy the library from `${WRKSRC}` to `${STAGEDIR}`. This may or may not be specific to tmpfs. You may want to try applying the attached patch to your FreeBSD 14 and 15 jails. It prevents `cp(1)` and `install(1)` from trying to use `copy_file_range(2)`. DES -- Dag-Erling Smørgrav - des@FreeBSD.org