ffmpeg - Abort trap 6

[Michael Newman]

Building from source seems to have worked:

Sellotape:~ mnewman$ port -v installed ffmpeg
The following ports are currently installed:
  ffmpeg @4.4.4_8+gpl2 (active) requested_variants='' platform='darwin 24' archs='x86_64' date='2024-10-03T12:05:08+0700’

I will do my best to file a report with Apple.

Thanks for the help.

> On Oct 3, 2024, at 11:14, Ryan Carsten Schmidt <ryandesign at macports.org> wrote:
> 
> On Oct 2, 2024, at 22:28, Michael Newman wrote:
>> 
>> Sellotape:bin mnewman$ file /opt/local/lib/libavcodec.58.dylib /opt/local/lib/libavcodec.58.134.100.dylib
>> /opt/local/lib/libavcodec.58.dylib:         data
>> /opt/local/lib/libavcodec.58.134.100.dylib: data
>> 
>> Unfortunately, I don’t recall if ffmpeg was built from source or via binary. Sorry.
>> 
>> This on a 2019 Intel iMac upgraded to Sequoia (15.0) just two days ago.
> 
> I can confirm this problem in the ffmpeg archive we produced on our macOS 15 x86_64 build machine. 
> 
> Large portions of that dylib file, including the beginning that allow the file command to identify what it is, are null bytes. The file has been corrupted. 
> 
> As far as I know, this is a bug in the APFS filesystem. The problem goes back to macOS 10.15 at least but we only learned about it more recently. 
> 
> Our ticket on this is https://trac.macports.org/ticket/67336. My Apple Feedback report about this is FB12160429. Apple has never acknowledged it or responded to it. Summarizing:
> 
> What happens is that the filesystem keeps track of which regions in a file are nulls ("holes") and represents the file sparsely so that those holes don't actually take up disk space. When we use tar to create an archive of files installed by a port, tar learns from the filesystem about those holes and also represents them sparsely in the archive, excluding those sections of the file from the archive, since they're supposed to be nulls. The bug is that the filesystem tells tar there are holes when in fact those holes had already been filled with data and should not be excluded, but there's no way for tar to know that the filesystem is lying. 
> 
> We have a workaround we can employ for root MacPorts installations (run /usr/sbin/purge before creating the tar archive to clear the filesystem cache) but we haven't implemented it in MacPorts base because we don't know a solution for non-root MacPorts installations. This fix has only been implemented manually in one port (pari). I had thought to write a PortGroup that could be included in affected ports, but there's no reason why only specific ports should be affected. It could affect any port and any file. 
> 
> BSD tar 3.6.0 and later can be told not to represent files sparsely which would work around the bug but even in macOS 15 Apple includes an older version of BSD tar than that. GNU tar can be told whether to represent files sparsely, and doesn't by default, but GNU tar isn't included in any macOS versions that support APFS. 
> 
> I could increase the revision of the ffmpeg port to rebuild it and make a new archive but there is no guarantee that the problem would not strike again, on any of the builders using the APFS filesystem.
> 
> For now, you can rebuild ffmpeg from source and hope that the issue does not occur on your machine:
> 
> sudo port -ns upgrade --force ffmpeg
> 
> Apple pays more attention to issues that affect more users, measured by how many duplicates a bug has. If this problem affects you please file a bug report with Apple and reference my 2023 bug number FB12160429 and the 2019 bug FB7378125 that I believe it's a duplicate of so that they can mark your bug as a duplicate and hopefully see how big a problem this is and start working on a fix. 
> 
> https://feedbackassistant.apple.com/
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20241003/5cf6b046/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1370 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20241003/5cf6b046/attachment.bin>