dunglas/mercure

Errors/crashes on apple silicon m2

mrozbarry opened this issue · 3 comments

I have a project that has been in development for a bit, and I recently brought in mercure, and it had been working great (on v0.15.10). I upgraded from an intel mac to an apple silicon m2/arm64 machine. Prior to this, I didn't notice any problems.

After getting my new machine, I've seen these behaviours

  • v0.15.10 for Darwin/arm64
    • Browser app can subscribe without issues, console logs it, and everything looks good
    • Using the built-in debug ui, publishing a message reported an error in the console, but I couldn't discern any particular message out of it
    • Rolling back to the default Caddyfile.dev had no effect
    • Using ctrl+c to kill server left a zombie process, and attempting to start a new instance would throw an error
      • I would have to pkill mercure to clean up
      • Sometimes that didn't work, but deleting the mercure.db file seemed to work when pkill did not
  • upgrade to v0.15.11 for Darwin/arm64
    • Immediate segfault when starting the server
  • downgrade back to v0.15.10 for Darwin/arm64
    • For reasons I can't fathom, also immediate segfaults, in spite of it working on my initial download

I'm pretty stumped, to be honest. I'm relatively familiar with arm/arm64 from raspberry pi, but can't seemed to figure out what's going on here.

I didn't see any issues specific to the m2, so I'm not certain if you have anyone else on this platform, and I'm not certain how to get you more debug information (but I'm willing to tinker if you have ideas). I'm not familiar with go, but don't mind being a guinea pig.

My current plan is to go through a linux x86/64 VM for my local development (and production is running linux), but I'd like to run things manually if possible.

Are you using the Docker image or a native Mac build?

Could you try to use lldb or gdb to get a stack trace?

Are you using the Docker image or a native Mac build?

Native

Could you try to use lldb or gdb to get a stack trace?

gdb isn't an option on arm, but I do have lldb.

Frustratingly, I have since both rebooted and re-downloaded, and so far running through lldb, things are working as expected. AND, running without lldb is now fine.

Last night, I did install rosetta, so I'm wondering if there was some piece of rosetta's install process that required a reboot and it just wasn't obvious.


I'm going to close this issue, but it might be worth noting for apple silicon systems that you should have rosetta installed, even with the native darwin/arm64 release.

Re-opening because it isn't expected. This is likely a bug in our CI pipeline. We recently migrated to the Apple Silicon boxes provided by GitHub. Previously we were using our own machines. Something is probably wrong in the migration.