firefox-bin-unwrapped: (their build)

otool -L result/Applications/Firefox.app/Contents/MacOS/firefox
result/Applications/Firefox.app/Contents/MacOS/firefox (architecture x86_64):
	@rpath/libmozglue.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 3502.1.255)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1900.180.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
result/Applications/Firefox.app/Contents/MacOS/firefox (architecture arm64):
	@rpath/libmozglue.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 3502.1.255)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1900.180.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

our build:

otool -L result/Applications/Firefox.app/Contents/MacOS/firefox
result/Applications/Firefox.app/Contents/MacOS/firefox:
	@rpath/libmozglue.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 3502.1.255)
	/nix/store/jl1421wiawqdgasrqqwd4d4jznvimfma-gettext-0.25.1/lib/libintl.8.dylib (compatibility version 13.0.0, current version 13.4.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1900.180.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

I have an alternative path to explore (adding a lot of debug messages in their png encoder to catch what happens there) but I'm lazy and want to bisect first. The crash is from access to an invalid memory address, and the code in question is:

void nsPNGEncoder::ConvertHostARGBRow(const uint8_t* aSrc, uint8_t* aDest,
                                      uint32_t aPixelWidth,
                                      bool aUseTransparency) {
  uint32_t pixelStride = aUseTransparency ? 4 : 3;
  for (uint32_t x = 0; x < aPixelWidth; x++) {
    const uint32_t& pixelIn = ((const uint32_t*)(aSrc))[x];
    uint8_t* pixelOut = &aDest[x * pixelStride];

    uint8_t alpha = (pixelIn & 0xff000000) >> 24;
    pixelOut[pixelStride - 1] = alpha;  // overwritten below if pixelStride == 3

The last line crashes. Either pixelOut is null, or the caller passes a non-transparent buffer (3-bytes per pixel while also requesting transparency).

Initially thought it's the new 144 version but 1) their crash reporter database caught some failures on 140 and 2) no relevant changes in the PNG encoder code of theirs that I could spot.

the name looks right, although i suppose i didn't actually check to make sure there wasn't some hidden character or some typo i just didn't see. i really don't know why xcrun is printing a warning about that with the nixpkgs SDK when the Xcode SDK has what looks like the exact same key. Does Swift Build care about that particular key?

My bigger concern is what I mentioned in the Nixpkgs / NixOS contributions room, which is that when I try to use Xcode to build a project with the nixpkgs SDK (not Xcode-in-nixpkgs but /usr/bin/xcodebuild, though I don't know if it actually makes a difference), I end up with what looks like a neverending stream of these warnings, several per second, with no other output. I don't know if the warning itself is actually a problem here or if there's some other reason why Xcode doesn't seem to actually be doing anything except printing these warnings

shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ mkdir -p usr/bin

shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ cat >usr/bin/xcrun
#!/usr/bin/env bash
echo oops

shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ chmod +x usr/bin/xcrun

shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ DEVELOPER_DIR=(pwd) /usr/bin/xcrun
oops