12 Jul 2025 |
Randy Eckenrode | In reply to @zhaofeng:zhaofeng.li IIRC the "error" always occurs for ad-hoc signed executables that the system has not seen before * | 18:43:11 |
Randy Eckenrode | In reply to @ihar.hrachyshka:matrix.org
ok added darwin.sigtool to native inputs but then
> ⨯ Command failed: codesign --sign - --force --timestamp --options runtime --entitlements /private/tmp/nix-build-podman-desktop-1.20.0.drv-0/source/node_modules/app-builder-lib/templates/entitlements.mac.plist /private/tmp/nix-build-podman-desktop-1.20.0.drv-0/source/dist/mac-arm64/Podman Desktop.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Resources/af.lproj/locale.pak
> The following arguments were not expected: --options --timestamp
> Run with --help for more information.
> failedTask=build stackTrace=Error: Command failed: codesign --sign - --force --timestamp --options runtime --entitlements /private/tmp/nix-build-podman-desktop-1.20.0.drv-0/source/node_modules/app-builder-lib/templates/entitlements.mac.plist /private/tmp/nix-build-podman-desktop-1.20.0.drv-0/source/dist/mac-arm64/Podman Desktop.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Resources/af.lproj/locale.pak
> The following arguments were not expected: --options --timestamp
sigtool is pretty primitive. You’ll probably have to rework it to use rcodesign . | 18:44:39 |
Sarah Clark | Anyone up for a mystery? pytorchCheckHook segfaults for some tests on some packages on Apple silicon: https://github.com/NixOS/nixpkgs/issues/423831 | 20:09:09 |
Randy Eckenrode | Is there a native stack trace from the crash? | 20:24:50 |
Randy Eckenrode | I reflexively want to blame GNU binutils for being in the torch closure, but I don’t think that’s it. | 20:29:36 |
Randy Eckenrode | (Can we use stdenv.cc.bintools instead of hardcoding binutils?) | 20:29:46 |
Randy Eckenrode | It just needs addr2line , which should be in it. | 20:29:59 |
Randy Eckenrode | python3Packages.torch is going to be broken by the Darwin minimum version bump …. | 20:31:47 |
Sarah Clark | I will see if I can pull a native stack trace. | 20:41:45 |
Sarah Clark | I'm bisecting around another broken package to see if it also converges on gpytorch | 20:42:05 |
Sarah Clark | * I'm currently bisecting around another broken package to see if it also converges on gpytorch | 20:42:27 |
Sarah Clark | Though, the common denominator is looking more like numpy | 20:42:47 |
Sarah Clark | Also, Thank You | 20:44:54 |
Sarah Clark | Here's the thread that crashed:
Thread 22 Crashed:
0 libomp.dylib 0x125575360 __kmp_suspend_initialize_thread + 32
1 libomp.dylib 0x125575e70 void __kmp_suspend_64<false, true>(int, kmp_flag_64<false, true>*) + 68
2 libomp.dylib 0x14726f988 kmp_flag_64<false, true>::wait(kmp_info*, int, void*) + 1936
3 libomp.dylib 0x14726aa78 __kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) + 168 4 libomp.dylib 0x14726e410 __kmp_fork_barrier(int, int) + 464 5 libomp.dylib 0x147245148 __kmp_launch_thread + 352 6 libomp.dylib 0x1472907f0 __kmp_launch_worker(void*) + 284 7 libsystem_pthread.dylib 0x18dff6c0c _pthread_start + 136 8 libsystem_pthread.dylib 0x18dff1b80 thread_start + 8
| 20:48:41 |
Randy Eckenrode | Thanks. That’s a crash in OpenMP. | 20:52:59 |
Randy Eckenrode | https://github.com/pytorch/pytorch/issues/149201 | 20:53:38 |
Sarah Clark | Of course, libomp | 20:54:23 |
Sarah Clark | D'oh | 20:54:26 |
Randy Eckenrode | I only see one llvmPackages.openmp in its closure. I don’t think it’s quite that upstream issue. | 20:55:50 |
Randy Eckenrode | Sarah Clark: Regarding the crash on x86_64-darwin you mentioned in that issue. Is it running on native hardware or under Rosetta 2? | 20:59:22 |
Randy Eckenrode | Rosetta 2 has some limitations in its floating point support that I have caused problems for numeric Python stuff in the past. | 20:59:40 |
Sarah Clark | I'ven had it happen on native hardware and on the build machines (Rosetta) | 21:00:07 |
Randy Eckenrode | If it affects native hardware, it’s very unlikely to be a Rosetta 2 issue. | 21:00:24 |
Sarah Clark | * I've had it happen on native hardware and on the build machines (Rosetta) | 21:00:30 |
Sarah Clark | Wait (checks logs), no I didn't repro it on nnative HW | 21:00:46 |
Sarah Clark | * Wait (checks logs), no I didn't repro it on native HW | 21:00:54 |
Sarah Clark | Rosetta seems likely. | 21:01:40 |
Sarah Clark | Hold on, yes it's happening on native aarch64 | 21:02:30 |
Sarah Clark | I had tested it on native x86 and it worked there too | 21:02:53 |
Sarah Clark | (nix-build -A python312Packages.gpytorch --check will show you the problem. In this case, it hangs forever. | 21:03:41 |