$ cat post/the-deploy-pipeline-/-the-socket-never-closed-right-/-i-kept-the-bash-script.md

the deploy pipeline / the socket never closed right / I kept the bash script


Title: Debugging My Way Through a M3 Pro Fiasco


October 9, 2023. Another day in the life of a platform engineer who’s seen it all and then some. Today, I found myself staring at an issue that seemed so simple yet stubbornly refused to yield to any solution I threw at it—like trying to convince a toddler that broccoli is delicious.

The Setup

The M3 Pro was supposed to be the highlight of this quarter. Apple’s latest processor promised a leap in performance and efficiency, but like every new hardware release, there were teething issues. Our team had spent weeks optimizing our applications for the M3 Pro, making sure we could harness its power without breaking any of our existing services.

The Issue

One Friday afternoon, I was paged by one of my engineers who reported a strange behavior in our logging service. It seemed that certain types of logs weren’t being processed correctly on machines running the new M3 Pro chips. Initially, I thought it must be some trivial configuration issue or maybe an environment variable that got mis-set somewhere.

But as I dove into the code and began to debug, the complexity of the problem became clear. The logging service was written in Rust, which we’ve used for years, but this new processor introduced some unexpected behavior related to WebAssembly (Wasm) execution. It turned out that a particular piece of Wasm code was failing to load properly on the M3 Pro.

The Investigation

I started by cross-referencing the error messages with known issues in Rust’s documentation and the latest version of the WebAssembly runtime for ARM64. I also reached out to some colleagues who had experience with both Rust and Wasm, but even their insights didn’t point directly to a solution.

It was during one of these fruitless debugging sessions that I stumbled upon a Reddit thread discussing similar issues in other projects. The discussion mentioned a known bug in the Apple toolchain related to stack alignment when running Wasm on ARM64 processors like M3 Pro. This was a red flag, and it led me to investigate further.

The Fix

After a couple of hours of digging through the code and referencing the Apple documentation, I finally found the culprit. It turns out that one of our Wasm modules had an incorrect stack alignment setting, which caused issues when running on the new M3 Pro chip. Once we updated this setting, the logs started processing correctly.

But here’s the funny part: we had already applied a similar fix for another project last year. I guess sometimes you just need to remember your own past work to solve future problems!

The Reflection

This experience reminded me of how important it is to stay current with both new hardware and the latest software changes. The M3 Pro brought with it a set of challenges that we didn’t encounter before, and it was clear that we needed to be more proactive in testing our applications on newer processors.

It also highlighted the importance of having thorough documentation and best practices for cross-platform compatibility. While I’m glad we caught this issue early enough to avoid any major service disruptions, it serves as a reminder that no matter how experienced you are, there’s always something new to learn.

The Takeaway

In the end, solving this issue wasn’t just about fixing code; it was about understanding the broader implications of hardware changes on our infrastructure. As we continue to integrate more server-side Wasm and deal with the ever-evolving landscape of technology, I’m reminded that patience and persistence are key to overcoming these challenges.

Until next time, happy debugging!


And there you have it—another day in my tech journal, full of unexpected twists and turns. If only logs could be as straightforward as they claim to be!