Why does running a clang compiled executable on a network drive, hang all subsequent executions of compiled executables?

Heath Raftery 0
Viewed 35

I'm perplexed by this one and not sure what's relevant so will include all context:

  • MacBook Pro with an M1 Pro running macOS 12.6.
  • Apple clang version 14.0.0, freshly installed by deleting DeveloperTools folder and running xcode-select --install.
  • Using zsh in Terminal.
  • Network share mounted using no-configuration Finder method (seems to use standard SMB, but authenticates with my Apple ID)
  • Network share is my home directory on a iMac with a Core i5 running macOS 11.6.8.
    • Update: also tried root directory and using the tmp directory, to eliminate one category of doubt. Same result.

The minimum repeatable example of the issue I've managed to find is:

  1. Use gcc from Apple's Developer Tools to compile a “Hello World” C application (originally discovered using ghc to compile Haskell - effect is the same).
  2. Run the compiled executable. No surprises.
  3. cd to the mounted network drive.
  4. Do the same thing there - compiled executable hangs! First surprise, but relatively minor.
  5. Return to the local machine. Original compiled executable still runs fine.
  6. Use the DeveloperTools to compile anything, including the original source - compiled executable on local machine now hangs!

I've created an asciinema recording of the MRE. You can see the key part of the transcript in this still:

Still from asciinema recording showing key part of the transcript

I’ve tried killing processes, checking lsof, unmounting the drive, logging in and out, checking the PATH, etc. Nothing gets me back to a working state short of a reboot.

Some more troubleshooting data:

  • gcc -v is identical for both executables, except for -fdebug-compilation-dir (set to cwd) and the name of the object file (randomly generated).
  • Just performing the compilation doesn't trigger the issue - running the networked executable does.
  • Trawling through the voluminous Console log reveals nothing relevant.
  • system.log shows no entries around the time of the issue.
  • lsof and ps -axww show reams and reams of output that is hard to spot patterns in, but I'm pretty sure there is no significant before/after differences.
  • I left the hung process running on the local machine overnight, and there's no change the next day.

Have I triggered some sandboxing or security fault and am being protected from disastrous consequences? Or this some clang/llvm related quirk I'm not familiar with? Or, given that ghc using its native code generator seems to have the same result, is this a bug in the way stdout is provided to executables? I'm at a loss!

console clang macos
1 Answers

Oh boy, avoiding Apple ID authentication of the network share fixed this for me.

I forced Finder to not use it’s magic no-configuration Apple ID login method, by opening the Location in Finder, clicking the "Disconnect" button and then clicking the "Connect As..." button that appears in its place. If I choose "Registered User" and use my username and password, I can then execute exactly the same commands (since the mount name ends up being the same) and execution works without an issue. I can continue to compile and execute to my heart's content.

That the Apple ID method is being used in the first place is not obvious (in true minimal design fashion), but subtly indicated at the top of the Finder window as "Connected as ". The only obvious difference this makes, is the username shown in mount:

Apple ID:

//com.apple.idms.appleid.prd.<UUID>@<HOSTNAME>._smb._tcp.local/<SHARE> on /Volumes/<SHARE> (smbfs, nodev, nosuid, mounted by <USERNAME>)

"Registered User":

//<USERNAME>@<HOSTNAME>._smb._tcp.local/<SHARE> on /Volumes/<SHARE> (smbfs, nodev, nosuid, mounted by <USERNAME>)

Obviously something far more significant is different, given the fundamental impact, but it's not at all clear to me what that is. So at this stage, this answer is just a workaround to a nasty bug.

Heath Raftery0
Related