hlissner
commented
5 years ago Does the issue go away if your remove liberime from your config?
Closed shuxiao9058 closed 4 years ago
hlissner
commented
5 years ago Does the issue go away if your remove liberime from your config?
shuxiao9058
commented
5 years ago always crash, this is my private doom config.
https://github.com/shuxiao9058/doom-emacs-private
With emacs -nw -Q, the emacs works fine.
hlissner
commented
5 years ago Does it work with your private config disabled? e.g.
mv ~/.doom.d ~/.doom.d.old
mkdir ~/.doom.d
cp ~/.doom.d.old/init.el ~/.doom.d/init.el
emacs -nw➜ .config mv doom doom_bak
➜ .config mkdir doom
➜ .config cp doom_/init.el ./doom
➜ .config emacs -nw
Fatal error 11: Segmentation fault[1] 32814 abort /usr/local/bin/emacs -nw
➜ .config@hlissner The same error.
hlissner
commented
5 years ago I'm stumped and cannot reproduce this. Have you tried reinstalling emacs-plus?
shuxiao9058
commented
5 years ago yes,the same when reinstall emacs-plus or install emas.
shuxiao9058
commented
5 years ago It was caused by doom-dashboard, it works fine when disable doom-dashboard.
hlissner
commented
5 years ago I've made some changes to the dashboard in f934f38. When you have some time, could you update and let me know if that resolves your segfaulting issue?
shuxiao9058
commented
5 years ago I've made some changes to the dashboard in f934f38. When you have some time, could you update and let me know if that resolves your segfaulting issue?
thee same error.
shuxiao9058
commented
5 years ago @hlissner It works fine with emacs 26.2 now.
shuxiao9058
commented
5 years ago this is backtrace
(lldb) r -nw
Process 37757 launched: '/usr/local/Cellar/emacs-plus/HEAD-68b374a/Emacs.app/Contents/MacOS/Emacs' (x86_64)
Process 37757 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTTOU
frame #0: 0x00007fff7516bb5a libsystem_kernel.dylib`__ioctl + 10
libsystem_kernel.dylib`__ioctl:
-> 0x7fff7516bb5a <+10>: jae 0x7fff7516bb64 ; <+20>
0x7fff7516bb5c <+12>: movq %rax, %rdi
0x7fff7516bb5f <+15>: jmp 0x7fff7516b421 ; cerror
0x7fff7516bb64 <+20>: retq
(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTTOU
* frame #0: 0x00007fff7516bb5a libsystem_kernel.dylib`__ioctl + 10
frame #1: 0x00007fff7516bb44 libsystem_kernel.dylib`ioctl + 151
frame #2: 0x00007fff750ad585 libsystem_c.dylib`tcsetattr + 110
frame #3: 0x00000001000bf502 Emacs`emacs_set_tty + 63
frame #4: 0x00000001000bff10 Emacs`init_sys_modes + 475
frame #5: 0x00000001000956ee Emacs`init_tty + 3765
frame #6: 0x000000010000d29d Emacs`init_display + 319
frame #7: 0x00000001000a9a71 Emacs`main + 5459
frame #8: 0x00007fff750363d5 libdyld.dylib`start + 1
thread #2
frame #0: 0x00007fff7516cbfe libsystem_kernel.dylib`__workq_kernreturn + 10
frame #1: 0x00007fff75229636 libsystem_pthread.dylib`_pthread_wqthread + 458
frame #2: 0x00007fff752293fd libsystem_pthread.dylib`start_wqthread + 13
thread #3
frame #0: 0x00007fff7516cbfe libsystem_kernel.dylib`__workq_kernreturn + 10
frame #1: 0x00007fff75229636 libsystem_pthread.dylib`_pthread_wqthread + 458
frame #2: 0x00007fff752293fd libsystem_pthread.dylib`start_wqthread + 13
thread #4, name = 'gmain'
frame #0: 0x00007fff7517336e libsystem_kernel.dylib`poll + 10
frame #1: 0x0000000101499c66 libglib-2.0.0.dylib`g_main_context_iterate + 422
frame #2: 0x0000000101499d74 libglib-2.0.0.dylib`g_main_context_iteration + 100
frame #3: 0x000000010149b956 libglib-2.0.0.dylib`glib_worker_main + 54
frame #4: 0x00000001014c49a2 libglib-2.0.0.dylib`g_thread_proxy + 66
frame #5: 0x00007fff7522a2eb libsystem_pthread.dylib`_pthread_body + 126
frame #6: 0x00007fff7522d249 libsystem_pthread.dylib`_pthread_start + 66
frame #7: 0x00007fff7522940d libsystem_pthread.dylib`thread_start + 13
zenobht
commented
5 years ago I got the same issue on 27.0.50 when using from terminal. This happens on my personal config which is not doom.
I narrowed to the package that causes it. Commenting evil-magit-init fixes it for me
(use-package evil-magit
:defer t
;; :init
;; (evil-magit-init)
:config
(bind-key "q" #'mu-magit-kill-buffers magit-status-mode-map)
)EDIT: Calling magit-status crashes emacs 27.0.50 in terminal.
(use-package magit
:defer t
:bind (("C-x g" . magit-status))
)EDIT: magit alone works fine. But with git-gutter it crashes. Seems like git-gutter is the issue
hlissner
commented
5 years ago I'm stumped. I'm half-convinced this has to do with a faulty build of Emacs (particularly 27 on MacOS) -- I cannot reproduce it on any of my systems, Linux or MacOS, and reports of these crashes seem to cover a wide area. Most of these reports appear to be related to functionality that manipulates the fringes or margins (which git-gutter, org-indent-mode, the Doom dashboard and magit-status all deal with). evil-magit-init is the outlier.
shuxiao9058
commented
5 years ago @hlissner Any plan to deal with this issue?
hlissner
commented
5 years ago @shuxiao9058 No. I don't understand the cause. I cannot reproduce it. It seems to be a Emacs 27-only issue, as well. No surprise bleeding edge Emacs will have bugs. Until (and if) I find a way to reproduce it, I suggest using 26.1/26.2 instead.
zenobht
commented
5 years ago I am using 26.2 right now. Emacs 27 is not stable with terminal. I was having random crashes with 27 on using daemon/frames.
hlissner
commented
5 years ago Is this still an issue?
shuxiao9058
commented
5 years ago yes
spudlyo
commented
4 years ago In order to reproduce this, you needs emacs 27.0.50, built with --with-ns (the default under macOS) and a minimal init.el with just git-gutter installed. You run emacs -nw some/file/under/revision/control and if you have an after-init-hook installed to run global-git-gutter-mode it segfaults every time. The file you open doesn't have to have unstaged changes. If you don't have the hook, you can get it to crash by M-x global-git-gutter-mode.
I built emacs 27 in a pretty straight-forward way, I cloned the source from Savannah, ran autogen.sh, then ran ./configure --prefix=/my/home/dir, and then built it with make. It was compiled with clang 9.0.0. If you build it using --without-ns there is no crash, so this is definitely a macOS related bug.
hlissner
commented
4 years ago @spudlyo That is odd. The fringe should be disabled in tty Emacs.
What does M-x eval-expression RET (display-graphic-p) return for you in NS builds of tty Emacs?
It's possible that the NS build tests for the existence of the define-fringe-bitmap function to determine whether Emacs should use the fringe or not. Doom creates a stub for it so that calls to it don't throw an error in tty Emacs. If that's the case, see if adding this to ~/.doom.d/config.el makes a difference:
(when (fboundp 'define-fringe-bitmap)
(fmakunbound 'define-fringe-bitmap))So (display-graphic-p) returns nil in my NS build of tty Emacs. I ran it in the debugger and found it was doing a null pointer dereference inside /src/nsterm.m which is apparently objective-c code. I patched the offending function with a test for a nil pointer, and now the crash is gone and I get my tty git-gutter as I expect.
I'm not actually a doom user (besides your awesome themes and mode line) so I don't know if your define-fringe-bitmap config change would make a difference, but I did submit a bug with the stack trace and my patch.
hlissner
commented
4 years ago @spudlyo Makes sense. Thanks so much for looking into it!
spudlyo
commented
4 years ago This was fixed upstream, and I can no-longer reproduce the crash after recompiling from master. I think you can close this one!
shuxiao9058
commented
4 years ago always crash...
spudlyo
commented
4 years ago Heya @shuxiao9058, the initial upstream fix for this didn't quite nail it 100%. Robert Pluim pushed a better fix for this today in commit 81b697d106. If you pull your emacs 27 branch now and rebuild this bug should be gone.
error run on iTerm with 'emacs -nw' as https://github.com/d12frosted/homebrew-emacs-plus/issues/112