Emacs.app installed via `brew install emacs-mac` not launching on macOS 13.0 Ventura (M1)

[orgtre]

When clicking on Emacs.app an Emacs process starts and is immediately quit without any message. Clicking "Show Package Contents" and running Contents/MacOS/Emacs launches a mostly working Emacs (only the meta/cmd key remappings are not in effect). The behavior is the same with Emacs.app from brew install --cask emacs-mac.

[inclyc]

It crashes by signal SIGSEGV on my laptop

Edit:

macOS 13.0.0

[railwaycat]

Sorry I can't reproduce this issue on my side. Can I get the output of your brew config command? That might be helpful for indicate the difference between your setup and mine.

Also, could you confirm this issue also shows when you start emacs by /Applications/Emacs.app/Contents/MacOS/Emacs -q?

[orgtre]

Sorry for the delay. The crash does only occur when clicking on Emacs.app. When clicking /Applications/Emacs.app/Contents/MacOS/Emacs or running this in terminal (both without and with the -q argument) it works.

Here is the brew config output: HOMEBREW_VERSION: 3.6.13-32-g93660d3 ORIGIN: https://github.com/Homebrew/brew HEAD: 93660d3de45f4d34289f8a0148ce5d7e3354f12e Last commit: 5 hours ago Core tap ORIGIN: https://github.com/Homebrew/homebrew-core Core tap HEAD: e3283b1690aa90f6995bec5fc30e8f656c75f9f2 Core tap last commit: 31 minutes ago Core tap branch: master HOMEBREW_PREFIX: /opt/homebrew HOMEBREW_CASK_OPTS: [] HOMEBREW_MAKE_JOBS: 10 Homebrew Ruby: 2.6.10 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby CPU: 10-core 64-bit arm_firestorm_icestorm Clang: 14.0.0 build 1400 Git: 2.38.1 => /opt/homebrew/bin/git Curl: 7.84.0 => /usr/bin/curl macOS: 13.0-arm64 CLT: 14.1.0.0.1.1666437224 Xcode: N/A Rosetta 2: false

[railwaycat]

Sorry I can't figure out the root cause of this issue and haven't able to reproduce on my side. There should no difference between start from the App bundle or from /Applications/Emacs.app/Contents/MacOS/Emacs. I would suspect maybe some part of your configuration triggered an issue of Emacs mac port? A "binary search" for configuration file could be the fastest method.

[jkthorne]

I am having the same problem on a brand new machine with an up to date install.

[jeff-phil]

I have had a random-ish crash for a while, and took time today to debug. This may help other crashers...

I found the problem was in here:

https://bitbucket.org/mituharu/emacs-mac/src/work/src/macappkit.m:906

Line (906) in that file is in the compiler directive #if MAC_USE_AUTORELEASE_LOOP which is defined when using clang, or the default LLVM c-compiler, vs. gcc. My fix was to change to the gcc compiler by doing this to link gcc earlier than clang gcc:

sudo ln -s $(which gcc-12) /opt/homebrew/bin/gcc

After making sure gcc is the homebrew gnu one, reinstall emacs-mac. No crashes yet for me, and performance is same (maybe better) but not measured.

[railwaycat]

Thanks @jeff-phil, that is an interesting found!

I'm not very sure about the behavior of Homebrew gcc installation though, is this behavior to avoid conflicts with the /usr/bin/gcc from macOS?

[milanglacier]

I felt the same error in macos 13 that emacsmac --with-nativecomp cannot be successfully installed.

Here's what I did:

brew remove gcc
brew install gcc libgccjit

brew install emacs-mac --with-nativecomp

and emacsmac now is successfully installed!

[thejeffphil]

@railwaycat Forgot to to respond, I spent last weekend debugging several things. It turns out that specific #if MAC_USE_AUTORELEASE_LOOP section is compiled in even after switching the gcc like I mentioned. I even tried with ARC support using -fobjc_arc but didn't help with the default ventura gcc over homebrew gcc.

Not sure what it is, but I can instantly make emacs crash unless using the gcc compiler from homebrew which generally runs without issue.

[tnytown]

@jeff-phil does Emacs crash if you use the system clang (/usr/bin/clang)? We might be running into a similar issue at https://github.com/NixOS/nixpkgs/issues/127902. Compiling Emacs with our non-system toolchain produces a binary that crashes.

[jeff-phil]

@tnytown - Yes, it was at one point. I just recompiled using system clang, to see if I could get it to crash again. I cannot remember how I used to get get it to crash, so may take a couple of days of running to trigger. And lots of system changes (ventura updates, brew updates, emacs 29, etc.) so not sure it's still apples to apples - but will see.

I may be confused reading through that long issue you linked, since issue starts as won't build. Then looks like it may build some with system clang and others without. In reading your latest I see your reference here as segfault issue when compiled with Homebrew-built clang but mine was originally crashing when using Apple's system clang. I originally saw some threads (I think it was around haskell on m1) that mentioned switching to homebrew's gcc (Apple gcc is basically a link to clang) so I tried it and worked at the time.

Lastly, I didn't see in that thread, but may be worth looking at the "elisp backtrace". See: https://github.com/emacs-mirror/emacs/blob/297ccd967f24e37bc51c057da43c862291a55ddd/etc/DEBUG#L1075C1-L1075C1 where you can load up in lldb, I just load it when needed: (lldb) command script import /emacs/path/to/etc/emacs_lldb.py and the emacs_lldb.py will enable the xbacktrace command in lldb. This will show the elisp stack to see what triggered it, which may (may not) be helpful.

[tnytown]

Thanks!

I may be confused reading through that long issue you linked, since issue starts as won't build. Then looks like it may build some with system clang and others without. In reading your latest I see your reference here as segfault issue when compiled with Homebrew-built clang but mine was originally crashing when using Apple's system clang. I originally saw some threads (I think it was around haskell on m1) that mentioned switching to homebrew's gcc (Apple gcc is basically a link to clang) so I tried it and worked at the time.

Yeah, my comments in that thread basically sum up the state of things, sorry for the fuss! The build issues are mostly resolved, and the issues now is getting GUI Emacs to run without crashing. Although it seems like I jumped the shark on judging that system clang compiles a working Emacs :(

Lastly, I didn't see in that thread, but may be worth looking at the "elisp backtrace".

That is very helpful, thank you!

[orgtre]

I tried this and this suggestion above, but Emacs still immediately quits.

[jeff-phil]

@orgtre This is pretty old thread, and not sure suggestions here are still good.

Does it immediately quit when running emacs -q?

Will you start emacs through lldb, at lldb prompt type r to run, then when crashes type bt at the lldb prompt to get backtrace and post here?

[orgtre]

Thanks @jeff-phil for your response. It doesn't quit when launching via terminal, with or without the q flag (see my old reply). Only when clicking on Emacs.app. My issue is exactly as originally described 1.5 years ago. It has forced me to use Emacs Plus instead, which unfortunately comes with its own set of issues. This distribution used to work better for me, so now when reinstalling Emacs, I thought I'd check if there is some solution to this issue by now.

[jeff-phil]

Okay, sorry missed previous about old reply. That is interesting in that old reply that if you launch directly it does not crash.

A couple of things to get to more details:

1. When you say only occur when clicking on Emacs.app any details on where are you clicking on Emacs.app?
2. What does this show: ls -ld /Applications/Emacs.app
3. If you run this does it crash: open /Applications/Emacs.app
4. If # 2 above crashes, can you launch with lldb /Applications/Emacs.app, then type r and then once crashes post bt backtrace.

[orgtre]

1. Where it is installed: /opt/homebrew/Cellar/emacs-mac/emacs-29.1-mac-10.0/Emacs.app, but the behavior is the same if I copy it to the Applications folder or try the cask instead. For the next steps I'm using the cask install. I'm just using Finder.
2. drwxr-xr-x@ 3 ooo staff 96B Aug 5 2023 /Applications/Emacs.app
3. No, it does not crash.
4. After I type r I get this message :

error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))

In Console.app I see a kernel process with this message:

macOSTaskPolicy: (com.apple.debugserver) may not get the task control port of (Emacs) (pid: 53139): (Emacs) is hardened, (Emacs) doesn't have get-task-allow, (com.apple.debugserver) is a declared debugger(com.apple.debugserver) is not a declared read-only debugger

[jeff-phil]

Have you considered building fresh? Here's what I use:

brew uninstall emacs-mac

HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source --debug-symbols emacs-mac --with-modules --with-native-comp --with-starter --with-emacs-big-sur-icon --with-mac-metal --with-unlimited-select --with-xwidgets --with-tree-sitter --with-librsvg --HEAD

rm -rf /Applications/Emacs.app

cp -r /opt/homebrew/Cellar/emacs-mac/*/Emacs.app /Applications/

Then can look and remove natively compiled modules, default is in ~/.emacs.d/eln-cache

Then start Emacs. If crashes, then now should work to start and run under lldb.