I am definitely not an expert, but: I saw this yesterday. It seemed to be encouraging me to retry, so I did. Same result. I tried several more times with increasing retry delays (an hour later, two hours later...). This morning I tried again, just for the heck of it, and it worked fine. I suggest simply retrying the conda install -c apple tensorflow-deps

I had come to his forum to report my problem, but reading recent posts, this one seems nearly identical. A few days ago I followed the instructions at https://developer.apple.com/metal/tensorflow-plugin/ and was able to run the simple (MNIST) proof-of-life suggested here https://caffeinedev.medium.com/how-to-install-tensorflow-on-m1-mac-8e9b91d93706 Then I tried to run my own Jupyter notebook I was using on Colab. It ran for 16 minutes then hung, the GPU usage dropped to zero, nothing further happened. This sounds very close to what @wangcheng reported last month.

I assume that TensorFlow on Metal on Apple Silicon is not a huge priority for Apple. Still, clearly some skilled engineering effort went into the current version. Which led some of us to buy M1 machines hoping to run our TensorFlow code on it. I write just in hopes this bug can be addressed “soonish.” Rereading @wangcheng’s report from two months ago, it says “If I train the model on CPU, it can finish training, and surprisingly near 20% faster each epoch.” I tried this in my code. I saw what I assume is more typical, on GPU my epochs were taking about 10 minutes (before it quit with the IOGPUResource), whereas on CPU it seems to be taking about 45 minutes per epoch.

Just FYI, 3 months ago I saw a similar leakage-until-mem-full problem on GPU. I found this forum and a now 4 month old report of what seemed an identical problem by user @wangcheng — The new tensorflow-macos and tensorflow-metal incapacitate training. I've been able to limp along by switching to CPU-only prediction since then.

Seems like a nasty bug to me. Or a huge step backwards in user experience. Apple please fix this! This issue was apparently raised in the beta version, but I don't run beta software, and still ran into this in the released version of Xcode in the course of a normal OS upgrade (13.5 → 13.5.2?)

@DTS Engineer : thanks for looking at this. Unfortunately, after working through your article, I essentially confirmed what I said above: “My open source project builds and runs fine in Xcode. But when I tested the CMake build, it failed looking for standard c++ headers.” Specifically: fatal error: 'iostream' file not found It is troubling to me that the only change from the beginning of this week — when the cmake build was working — and now — was to install a “point” update to MacOS 14. It looks like that minor update managed to break a widely used open source tool.

I return with an update. I had a reply to my stackoverflow question from user @MihaiChelaru. He saw what appears to be the exact same failure, at the exact same macOS upgrade. In his research he found a solution: forcing a full reload of CTL with sudo rm -rf /Library/Developer/CommandLineTools. After doing that (and some other macOS stuff as described in the SO post) my CMake build was miraculously cured! While my c++ project has definitely changed in the 20 days, it was still failing the same way when I tested it today before deleting CLT. But importantly (in my opinion) my installation of CMake is unchanged as is my project's build script (called CMakeLists.txt). So: CMake build was working I installed macOS 14.7.2 and Xcode 16.2 CMake build stopped working I deleted my /Library/Developer/CommandLineTools, etc. CMake build started working again I am certainly not in charge of how Apple chooses to allocate its software maintenance resources. But it would be super simple to create a minimal test in an acceptance suite to build a CMake hello.c project. Or possibly, explicitly clearing a user's CLT folder before switching? Having been in your shoes, I know these policy issues always seem simple from the outside. But as a long time Mac user, I felt duty-bound to make sure this information made it back to you.