> On 10.09.2023, at 16:08, Gerd Möllmann wrote: > > Christian Tanzer via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > >>> On 09.09.2023, at 18:40, Eli Zaretskii wrote: >>> >>>> From: Christian Tanzer >>>> Date: Sat, 9 Sep 2023 18:36:07 +0100 >>>> Cc: 65843@debbugs.gnu.org >>>> >>>>> On 09.09.2023, at 17:49, Eli Zaretskii wrote: >>>>> >>>>> Thanks, can you run Emacs 29 under a debugger and show a backtrace >>>>> when it crashes? >>>> >>>> Unfortunately, I don’t have a C development environment setup on my little MacBook (and haven’t used gdb for more than 20 years besides). >>> >>> Backtrace from LLDB will be also helpful. Without a crash backtrace, >>> we will have to wait until someone can reproduce the crashes on a >>> system where a debugger _is_ available. >> >> It took me a while to get lldb to run emacs (missing get-task-value entitlement), and then: >> running under lldb, emacs doesn’t crash, but it also doesn’t open any >> frames: > > Could you please tell which LLDB this is > > lldb --version > > and how you installed it? The missing entitlement is strange. lldb --version lldb-1205.0.27.3 Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55) I didn’t install lldb itself, but I assume it was installed together with the Xcode command line tools. The entitlement seems to be a frequent issue but it is very hard to find in DuckDuckGo. > >>> lldb /Applications/Emacs-28.2.app/Contents/MacOS/Emacs >>> (lldb) target create "/Applications/Emacs-28.2.app/Contents/MacOS/Emacs" >>> Current executable set to >>> '/Applications/Emacs-28.2.app/Contents/MacOS/Emacs' (arm64). >>> (lldb) run >>> Process 22971 launched: '/Applications/Emacs-28.2.app/Contents/MacOS/Emacs' (arm64) >>> Process 22971 exited with status = 0 (0x00000000) >>> (lldb) ^D > > This looks correct to me. Except for Emacs exiting without doing anything?