search

emacs-helm / helm

Emacs incremental completion and selection narrowing framework
https://emacs-helm.github.io/helm/
GNU General Public License v3.0
3.36k stars 389 forks source link

helm-locate-library + pattern starting with "j" crashes Emacs #779

Closed vkz closed 9 years ago

vkz commented 9 years ago

Everything is freshly installed from MELPA (Helm version 20141225.14). Doing nothing fancy. Was just trying to locate js2-refactor library. Pattern: refa etc works fine. Any pattern that starts with j like say js2-re flat out crashes Emacs. Always. Tested with my old .emacs.d where I haven't updated any packages for a while and it seems to work just fine (Helm version 20141007).

thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

Everything is freshly installed from MELPA (Helm version 20141225.14). Doing nothing fancy. Was just trying to locate js2-refactor library. Pattern: refa etc works fine. Any pattern that starts with j like say js2-re flat out crashes Emacs. Always. Tested with my old .emacs.d where I haven't updated any packages for a while and it seems to work just fine (Helm version 20141007).

I have installed from MELPA js2-refactor and tried to reproduce your issue with no success, can you try from ./emacs-helm.sh ?

Thanks.

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

vkz commented 9 years ago

@thierryvolpiatto reproduced using ./emacs-helm.sh

Since I'm running a GUI app on Mac OS X (official GNU Emacs installed from Homebrew) let's "compare apples with apples" by amending the ./emacs-helm.sh:

replace: EMACS=emacs with: EMACS='open -a Emacs.app -n --args '

and add path to helm to 'load-path explicitly cause changing the executable above messes with the path so the (require 'helm-config) fails. No idea why, I can barely read shell-scripts: (add-to-list 'load-path (file-name-directory "/Users/kozin/.personal_configs/emacs.candidate/elpa/helm-20141225.14/emacs-helm.sh"))

Now running ./emacs-helm.sh as usual will start GUI version of emacs no problem. Helm works as expected in the clean environment, nothing is polluted with custom modifications. M-x helm-locate-library Pattern: j

Emacs stalls for like 3 sec and crashes. I should mention that everything works fine in the non-GUI version, i.e. in the terminal. Very well maybe the case that this should be reported elsewhere. Advice how to proceed? So far the issue's been only with helm-locate-library in GUI app.

I'm running this on: "GNU Emacs 24.4.1 (x86_64-apple-darwin14.0.0, NS apple-appkit-1343.14) of 2014-11-03 on kozin-osx.local"

vkz commented 9 years ago

I should probably stress that it appears to have nothing to do with js2-refactor. I can obviously just avoid using helm-locate-library but hey what if there's a bigger issue. Like said appreciate this maybe worth reporting elsewhere.

thierryvolpiatto commented 9 years ago

Please is there someone on Macosx that can reproduce this bug, I don't see why it would fail with "j" and not another character.

Thanks.

vkz commented 9 years ago

Unfortunately, I have noone around who uses Emacs to try and test this. But I also tried this with an older version of Helm

helm-20141007.2253 works fine helm-20141225.14 crashes

Ran both with their relevant ./emacs-helm.sh in each case. Emacs version stayed the same.

thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

Unfortunately, I have noone around who uses Emacs to try and test this. But I also tried this with an older version of Helm

helm-20141007.2253 works fine helm-20141225.14 crashes

Ran both with their relevant ./emacs-helm.sh in each case. Emacs version stayed the same.

Can you uninstall your helm from melpa and install from git using the make file.

Thanks.

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

thierryvolpiatto commented 9 years ago

Also to see what is happening, could you run your emacs from gdb?

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

vkz commented 9 years ago 
bash-3.2$ pwd
/Users/kozin/.personal_configs/emacs.candidate/site-lisp
bash-3.2$ git clone https://github.com/emacs-helm/helm
Cloning into 'helm'...
remote: Counting objects: 18054, done.        
remote: Compressing objects: 100% (59/59), done.        
remote: Total 18054 (delta 33), reused 3 (delta 1)        
Receiving objects: 100% (18054/18054), 15.90 MiB | 4.99 MiB/s, done.
Resolving deltas: 100% (11647/11647), done.
Checking connectivity... done.
bash-3.2$ cd helm/
bash-3.2$ make

... amend ./emacs-helm.sh as per above description ... EMACS='open -a Emacs.app -n --args ' (add-to-list 'load-path (file-name-directory "/Users/kozin/.personal_configs/emacs.candidate/site-lisp/helm/emacs-helm.sh"))

bash-3.2$ pwd
/Users/kozin/.personal_configs/emacs.candidate/site-lisp/helm
bash-3.2$ ./emacs-helm.sh

Search for library starting with j and kabooom we crash.

vkz commented 9 years ago

I failed to make gdb work on OS X. Some codesigning issue which I thought I did. Anyway. Here's a crash report from lldb. Would this help? This is almost completely unfamiliar territory for me, so not sure how much help I can be:

kozin           31405   0.0  0.5  2614588  43456   ??  S     4:45PM   0:01.43 /usr/local/Cellar/emacs/24.4/Emacs.app/Contents/MacOS/Emacs -Q -l /tmp/helm-cfg.el
95:helm kozin$ lldb -p 31405
(lldb) process attach --pid 31405
Process 31405 stopped
Executable module set to "/usr/local/Cellar/emacs/24.4/Emacs.app/Contents/MacOS/Emacs".
Architecture set to: x86_64h-apple-macosx.
(lldb) c
Process 31405 resuming
Process 31405 stopped
* thread #1: tid = 0x7e2d0c, 0x00007fff92d2ec7e libsystem_kernel.dylib`__kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff92d2ec7e libsystem_kernel.dylib`__kill + 10
libsystem_kernel.dylib`__kill + 10:
-> 0x7fff92d2ec7e:  jae    0x7fff92d2ec88            ; __kill + 20
   0x7fff92d2ec80:  movq   %rax, %rdi
   0x7fff92d2ec83:  jmp    0x7fff92d2aca3            ; cerror_nocancel
   0x7fff92d2ec88:  retq   
(lldb) bt
* thread #1: tid = 0x7e2d0c, 0x00007fff92d2ec7e libsystem_kernel.dylib`__kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff92d2ec7e libsystem_kernel.dylib`__kill + 10
    frame #1: 0x00000001000a2931 Emacs`terminate_due_to_signal + 149
    frame #2: 0x00000001000bbbc0 Emacs`emacs_abort + 19
    frame #3: 0x00000001001774c9 Emacs`ns_term_shutdown + 124
    frame #4: 0x00000001000a2b1b Emacs`shut_down_emacs + 283
    frame #5: 0x00000001000a28f5 Emacs`terminate_due_to_signal + 89
    frame #6: 0x00000001000bbbc0 Emacs`emacs_abort + 19
    frame #7: 0x000000010018059a Emacs`ns_read_socket + 606
    frame #8: 0x00000001000a873b Emacs`gobble_input + 276
    frame #9: 0x00000001000ace43 Emacs`get_input_pending + 91
    frame #10: 0x00000001000a8e5f Emacs`read_char + 693
    frame #11: 0x00000001000a6f2d Emacs`read_key_sequence + 1566
    frame #12: 0x00000001000a66e2 Emacs`command_loop_1 + 4076
    frame #13: 0x0000000100110d0a Emacs`internal_condition_case + 251
    frame #14: 0x00000001000b4b89 Emacs`command_loop_2 + 53
    frame #15: 0x0000000100110725 Emacs`internal_catch + 243
    frame #16: 0x00000001000a4f04 Emacs`recursive_edit_1 + 264
    frame #17: 0x00000001000cc61e Emacs`read_minibuf + 1976
    frame #18: 0x00000001000cbe3f Emacs`Fread_from_minibuffer + 250
    frame #19: 0x00000001001124e0 Emacs`Ffuncall + 1286
    frame #20: 0x0000000100144c87 Emacs`exec_byte_code + 2147
    frame #21: 0x000000010011222d Emacs`Ffuncall + 595
    frame #22: 0x0000000100144c87 Emacs`exec_byte_code + 2147
    frame #23: 0x000000010011222d Emacs`Ffuncall + 595
    frame #24: 0x000000010010f13a Emacs`eval_sub + 1387
    frame #25: 0x0000000100110ad3 Emacs`internal_lisp_condition_case + 543
    frame #26: 0x0000000100145ab2 Emacs`exec_byte_code + 5774
    frame #27: 0x000000010011222d Emacs`Ffuncall + 595
    frame #28: 0x000000010010f13a Emacs`eval_sub + 1387
    frame #29: 0x0000000100110725 Emacs`internal_catch + 243
    frame #30: 0x0000000100145873 Emacs`exec_byte_code + 5199
    frame #31: 0x000000010011222d Emacs`Ffuncall + 595
    frame #32: 0x0000000100111e71 Emacs`Fapply + 523
    frame #33: 0x00000001001122d3 Emacs`Ffuncall + 761
    frame #34: 0x0000000100144c87 Emacs`exec_byte_code + 2147
    frame #35: 0x000000010011222d Emacs`Ffuncall + 595
    frame #36: 0x0000000100111e71 Emacs`Fapply + 523
    frame #37: 0x00000001001122d3 Emacs`Ffuncall + 761
    frame #38: 0x0000000100144c87 Emacs`exec_byte_code + 2147
    frame #39: 0x000000010011222d Emacs`Ffuncall + 595
    frame #40: 0x0000000100144c87 Emacs`exec_byte_code + 2147
    frame #41: 0x000000010011222d Emacs`Ffuncall + 595
    frame #42: 0x000000010010e9e1 Emacs`apply1 + 53
    frame #43: 0x000000010010cd69 Emacs`Fcall_interactively + 1153
    frame #44: 0x00000001001123e9 Emacs`Ffuncall + 1039
    frame #45: 0x0000000100144c87 Emacs`exec_byte_code + 2147
    frame #46: 0x000000010011222d Emacs`Ffuncall + 595
    frame #47: 0x0000000100144c87 Emacs`exec_byte_code + 2147
    frame #48: 0x000000010011222d Emacs`Ffuncall + 595
    frame #49: 0x000000010010e9e1 Emacs`apply1 + 53
    frame #50: 0x000000010010cd69 Emacs`Fcall_interactively + 1153
    frame #51: 0x00000001001123e9 Emacs`Ffuncall + 1039
    frame #52: 0x0000000100144c87 Emacs`exec_byte_code + 2147
    frame #53: 0x000000010011222d Emacs`Ffuncall + 595
    frame #54: 0x0000000100112882 Emacs`call1 + 45
    frame #55: 0x00000001000a61f8 Emacs`command_loop_1 + 2818
    frame #56: 0x0000000100110d0a Emacs`internal_condition_case + 251
    frame #57: 0x00000001000b4b89 Emacs`command_loop_2 + 53
    frame #58: 0x0000000100110725 Emacs`internal_catch + 243
    frame #59: 0x00000001000a4ecf Emacs`recursive_edit_1 + 211
    frame #60: 0x00000001000a5075 Emacs`Frecursive_edit + 236
    frame #61: 0x00000001000a3f8a Emacs`main + 5142
    frame #62: 0x00007fff87dad5c9 libdyld.dylib`start + 1
    frame #63: 0x00007fff87dad5c9 libdyld.dylib`start + 1
thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

bash-3.2$ pwd /Users/kozin/.personal_configs/emacs.candidate/site-lisp bash-3.2$ git clone https://github.com/emacs-helm/helm Cloning into 'helm'... remote: Counting objects: 18054, done.
remote: Compressing objects: 100% (59/59), done.
remote: Total 18054 (delta 33), reused 3 (delta 1)
Receiving objects: 100% (18054/18054), 15.90 MiB | 4.99 MiB/s, done. Resolving deltas: 100% (11647/11647), done. Checking connectivity... done. bash-3.2$ cd helm/ bash-3.2$ make

... amend ./emacs-helm.sh as per above description ... EMACS='open -a Emacs.app -n --args ' (add-to-list 'load-path (file-name-directory "/Users/kozin/.personal_configs/emacs.candidate/site-lisp/helm/emacs-helm.sh"))

bash-3.2$ pwd /Users/kozin/.personal_configs/emacs.candidate/site-lisp/helm bash-3.2$ ./emacs-helm.sh

Search for library starting with j* and kabooom we crash.

Seems it is really a problem with your emacs, you may have the same problem in other places out of helm. Does setting

(setq max-lisp-eval-depth 40000) (setq max-specpdl-size 100000)

helps?

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

vkz commented 9 years ago

setting those limits doesn't help

michael-heerdegen commented 9 years ago

Reading the definition of gobble_input in keyboard.c, Emacs kills itself because "/* The terminal device terminated; it should be closed. */". Dunno why this happens. I would ask Eli.

vkz commented 9 years ago

tried switching to relevant frames in the stack trace above and getting their arguments and local vars, but unfortunately frame variable wouldn't print anything.

vkz commented 9 years ago

@michael-heerdegen afraid I dunno who Eli is. Is there anything I could do on my side to help debug this further?

michael-heerdegen commented 9 years ago

vkz notifications@github.com writes:

@michael-heerdegen afraid I dunno who Eli is

Eli Zaretskii, the Emacs developer. I didn't mean you should contact him ;-)

Is there anything I could do on my side to help debug this further?

Not really. Maybe try to vary your recipe, e.g. try with multiple open frames, or use the character j as second letter of the search string etc.

I still wonder why it is "j" that causes the crash and not any other character.

vkz commented 9 years ago

did try to vary the recipe quite a bit. "j" not in the 1st position etc. Even switched keyboards. So far only the "j" in 1st position seems to crash the app (on both keyboards).

@thierryvolpiatto is probably right in saying that helm-locate-library may not even be at fault here but rather some core-emacs functions that it calls. Emacs has been kinda crashy for me. It's just the first time I'm able to pinpoint and reproduce that moment.

tuhdo commented 9 years ago

Probably you could try Emacs for Mac OS X to see if the problem persists?

thierryvolpiatto commented 9 years ago

BTW the old helm version you used and was not crashing is not probably using fuzzy matching, so after evaling the code below, you should not crash (fuzzy disabled):

(defun helm-locate-library () (interactive) (helm :sources (helm-build-in-buffer-source "Elisp libraries (Scan)" :data (lambda () (helm-locate-library-scan-list)) ;:fuzzy-match t :keymap helm-generic-files-map :match-part (lambda (candidate) (if helm-ff-transformer-show-only-basename (helm-basename candidate) candidate)) :filter-one-by-one (lambda (c) (if helm-ff-transformer-show-only-basename (cons (helm-basename c) c) c)) :action (helm-actions-from-type-file)) :buffer "helm locate library"))

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

vkz commented 9 years ago

@tuhdo I could and it would maybe solve my problem, but I'd rather go with vanilla Emacs. And if there's indeed a problem with some core emacs functionality, I think devs should know. Crashing editors aren't fun.

@thierryvolpiatto disabling fuzzy, that is rebinding the function as per your advice, doesn't seem to make a difference :(

thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

@tuhdo I could and it would maybe solve my problem, but I'd rather go with vanilla Emacs. And if there's indeed a problem with some core emacs functionality, I think devs should know. Crashing editors aren't fun.

@thierryvolpiatto disabling fuzzy, that is rebinding the function as per your advice, doesn't seem to make a difference :(

Huh! so your emacs have a serious problem. Hmm! What I really doesn't understand (as already said) is the "j" problem, why "j" why not "a" or "b" ? And you said also the problem doesn't appear in emacs -nw, right ? Isn't emacs (X) interpreting "j" (or what "j" represent on your keyboard) as some unicode character or something like this (just a thought) ?

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

@tuhdo I could and it would maybe solve my problem, but I'd rather go with vanilla Emacs. And if there's indeed a problem with some core emacs functionality, I think devs should know. Crashing editors aren't fun.

Even if you want to use you current emacs, perhaps following the advice of @tuhdo would help (i.e installing temporarily the optimized version of emacs for macosx). Having several versions of emacs installed is not a problem, I can help you to manage this if you want, I have a script to switch to different versions installed.

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

tuhdo commented 9 years ago

@vkz But you should try to see if it is a specific problem from a Homebrew build or universal in Mac OS X. If it occurs so frequent, probably other users in Mac OS X would report too.

lewang commented 9 years ago

@vkz Where did you download your Emacs from? Or did you compile it yourself?

vkz commented 9 years ago

@lewang brew install emacs --cocoa --srgb which I think builds from source

@tuhdo tried Emacs for Mac OS X with precisely the same result

@thierryvolpiatto sure, I'd gladly have a look at the script. I juggle a bunch of .emacs.d with symlinks but having ability to easily switch Emacs binaries sounds neat.

I should add that I use Dvorak so the physical key I'm pressing is actually c. But I can't imagine how that could be a problem. I'm using vanilla Dvorak layout that ships with Mac.

vkz commented 9 years ago

Installed Emacs from HEAD

"GNU Emacs 25.0.50.1 (x86_64-apple-darwin14.0.0, NS appkit-1343.16 Version 10.10.1 (Build 14B25)) of 2014-12-28 on kozin-osx.local"

Now the same steps don't crash it but it does go into insane mode while in helm-locate-library as in it tries to narrow, takes ages, trying to type any other character echoes nonsense (actually a repeated pattern, see below). Deleting the pattern and typing something else doesn't work. C-g to escape from this command brings Emacs to "normal" but like I mentioned above every char is now prepended with a few others. Here's me trying to type SPACE, a, b, c, d, e etc each on its own line:

stobho
stobhoa
stobhob
stobhoc
stobhod
stobhoe
stobhof
stobhog
stobhoh
stobhoi
stobhoj
stobhok

I should mention again that all of those Emacs versions seem to work fine with older version of Helm. This is so bizarre -) I think trying to catch what character is being sent in attached debugger is the way forward but I'm unable to get arguments in lldb frames. No idea why.

lewang commented 9 years ago

I followed your repro steps with my own built yamamoto version. Although it did not crash for me, pressing "j" took (4-5 seconds) while pressing "e" responds instantaneously, even though "e" yields many more results.

On Sun, Dec 28, 2014 at 4:21 PM, vkz notifications@github.com wrote:

Installed Emacs from HEAD

"GNU Emacs 25.0.50.1 (x86_64-apple-darwin14.0.0, NS appkit-1343.16 Version 10.10.1 (Build 14B25)) of 2014-12-28 on kozin-osx.local"

Now the same steps don't crash it but it does go into insane mode while in helm-locate-library as in it tries to narrow, takes ages, trying to type any other character echoes nonsense (actually a repeated pattern, see below). Deleting the pattern and typing something else doesn't work. C-g to escape from this command brings Emacs to "normal" but like I mentioned above every char is now prepended with a few others. Here's me trying to type SPACE, a, b, c, d, e etc each on its own line:

stobho stobhoa stobhob stobhoc stobhod stobhoe stobhof stobhog stobhoh stobhoi stobhoj stobhok

I should mention again that all of those Emacs versions seem to work fine with older version of Helm. This is so bizarre -) I think trying to catch what character is being sent in attached debugger is the way forward but I'm unable to get arguments in lldb frames. No idea why.

— Reply to this email directly or view it on GitHub https://github.com/emacs-helm/helm/issues/779#issuecomment-68219914.

Le

thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

@thierryvolpiatto sure, I'd gladly have a look at the script.

https://github.com/thierryvolpiatto/shell_scripts/blob/master/eselect-emacs.sh

To use this script you have to install emacs as follow:

1) Remove all emacs binaries in PATH. 2) Install your differents emacs (replace VERSION):

sudo make install bindir=/usr/local/sbin/emacs- infodir=/usr/local/share/info-

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

Installed Emacs from HEAD

"GNU Emacs 25.0.50.1 (x86_64-apple-darwin14.0.0, NS appkit-1343.16 Version 10.10.1 (Build 14B25))
of 2014-12-28 on kozin-osx.local"

Well emacs-25.5 should be even more unstable...

Now the same steps don't crash it but it does go into insane mode while in helm-locate-library as in it tries to narrow, takes ages, trying to type any other character echoes nonsense (actually a repeated pattern, see below). Deleting the pattern and typing something else doesn't work. C-g to escape from this command brings Emacs to "normal" but like I mentioned above every char is now prepended with a few others. Here's me trying to type SPACE, a, b, c, d, e etc each on its own line:

I don't understand exactly what is happening here, can you clarify ?

I should mention again that all of those Emacs versions seem to work fine with older version of Helm.

Could you locate last working version (git) ?

This is so bizarre -) I think trying to catch what character is being sent in attached debugger is the way forward but I'm unable to get arguments in lldb frames. No idea why.

Isn't there directions to install gdb in Mac somewhere ? Would be great you run your crashing emacs inside gdb, starting emacs from the src/ directory, then running bt and/or xbacktrace would give us precious informations. For more infos on how debugging emacs see M-x view-emacs-debugging (C-h C-d)

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

thierryvolpiatto commented 9 years ago

Le Wang notifications@github.com writes:

I followed your repro steps with my own built yamamoto version. Although it did not crash for me, pressing "j" took (4-5 seconds) while pressing "e" responds instantaneously, even though "e" yields many more results.

Can you figure out why "j" and not "e" ? What describe-char' give on "j" ? Can you try to input "j" usingC-q j' ?

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

vkz commented 9 years ago

Can you figure out why "j" and not "e" ? What describe-char' give on "j" ? Can you try to input "j" usingC-q j' ?

nothing untoward for me

             position: 192 of 192 (99%), column: 0
            character: j (displayed as j) (codepoint 106, #o152, #x6a)
    preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x6A
               script: latin
               syntax: w    which means: word
             category: .:Base, L:Left-to-right (strong), a:ASCII, l:Latin, r:Roman
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
          buffer code: #x6A
            file code: #x6A (encoded by coding system utf-8)
              display: by this font (glyph code)
    mac-ct:-*-Monaco-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1 (#x4D)

Character code properties: customize what to show
  name: LATIN SMALL LETTER J
  general-category: Ll (Letter, Lowercase)
  decomposition: (106) ('j')

There are text properties here:
  fontified            t
vkz commented 9 years ago

Isn't there directions to install gdb in Mac somewhere ? Would be great you run your crashing emacs inside gdb, starting emacs from the src/ directory, then running bt and/or xbacktrace would give us precious informations.

There're and I followed them. For whatever reason the codesigning doesn't seem to work for me. My guess is I need to reboot, which I'd rather avoid for now - too much in the works and it'd be a major disruption. I did however collect the backtrace at crash-site in lldb - see an earlier post above. I doubt GDB would give any more information. Here's a report that OS X generates on crash:

Process:               Emacs-x86_64-10_9 [85407]
Path:                  /Applications/Emacs24.app/Contents/MacOS/Emacs-x86_64-10_9
Identifier:            org.gnu.Emacs
Version:               Version 24.4 (9.0)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Emacs-x86_64-10_9 [85407]

Date/Time:             2014-12-29 10:43:47.185 +0300
OS Version:            Mac OS X 10.10.1 (14B25)
Report Version:        11

Time Awake Since Boot: 830000 seconds
Time Since Wake:       740 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff92d2ec7e __kill + 10
1   Emacs-x86_64-10_9               0x00000001000d5773 emacs_abort + 19
2   Emacs-x86_64-10_9               0x00000001001a72dc ns_term_shutdown + 124
3   Emacs-x86_64-10_9               0x00000001000b853b shut_down_emacs + 283
4   Emacs-x86_64-10_9               0x00000001000b8309 terminate_due_to_signal + 89
5   Emacs-x86_64-10_9               0x00000001000d5773 emacs_abort + 19
6   Emacs-x86_64-10_9               0x00000001001b29fd ns_read_socket + 717
7   Emacs-x86_64-10_9               0x00000001000bf1df gobble_input + 287
8   Emacs-x86_64-10_9               0x00000001000c1ac2 detect_input_pending_run_timers + 114
9   Emacs-x86_64-10_9               0x00000001000bfa2b read_char + 667
10  Emacs-x86_64-10_9               0x00000001000bd663 read_key_sequence + 1859
11  Emacs-x86_64-10_9               0x00000001000bccf4 command_loop_1 + 5188
12  Emacs-x86_64-10_9               0x0000000100137ecb internal_condition_case + 251
13  Emacs-x86_64-10_9               0x00000001000cd13e command_loop_2 + 62
14  Emacs-x86_64-10_9               0x0000000100137863 internal_catch + 243
15  Emacs-x86_64-10_9               0x00000001000baeb2 recursive_edit_1 + 274
16  Emacs-x86_64-10_9               0x00000001000ea18f read_minibuf + 1999
17  Emacs-x86_64-10_9               0x00000001000e998a Fread_from_minibuffer + 250
18  Emacs-x86_64-10_9               0x000000010013986f Ffuncall + 1423
19  Emacs-x86_64-10_9               0x0000000100171e3b exec_byte_code + 2331
20  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
21  Emacs-x86_64-10_9               0x0000000100171e3b exec_byte_code + 2331
22  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
23  Emacs-x86_64-10_9               0x0000000100135dd4 eval_sub + 1540
24  Emacs-x86_64-10_9               0x0000000100137c4a internal_lisp_condition_case + 554
25  Emacs-x86_64-10_9               0x0000000100172cc5 exec_byte_code + 6053
26  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
27  Emacs-x86_64-10_9               0x0000000100135dd4 eval_sub + 1540
28  Emacs-x86_64-10_9               0x0000000100137863 internal_catch + 243
29  Emacs-x86_64-10_9               0x0000000100172a82 exec_byte_code + 5474
30  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
31  Emacs-x86_64-10_9               0x000000010013916d Fapply + 541
32  Emacs-x86_64-10_9               0x0000000100139610 Ffuncall + 816
33  Emacs-x86_64-10_9               0x0000000100171e3b exec_byte_code + 2331
34  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
35  Emacs-x86_64-10_9               0x000000010013916d Fapply + 541
36  Emacs-x86_64-10_9               0x0000000100139610 Ffuncall + 816
37  Emacs-x86_64-10_9               0x0000000100171e3b exec_byte_code + 2331
38  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
39  Emacs-x86_64-10_9               0x0000000100171e3b exec_byte_code + 2331
40  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
41  Emacs-x86_64-10_9               0x00000001001355b5 apply1 + 53
42  Emacs-x86_64-10_9               0x00000001001335d8 Fcall_interactively + 1272
43  Emacs-x86_64-10_9               0x0000000100139792 Ffuncall + 1202
44  Emacs-x86_64-10_9               0x0000000100171e3b exec_byte_code + 2331
45  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
46  Emacs-x86_64-10_9               0x0000000100171e3b exec_byte_code + 2331
47  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
48  Emacs-x86_64-10_9               0x00000001001355b5 apply1 + 53
49  Emacs-x86_64-10_9               0x00000001001335d8 Fcall_interactively + 1272
50  Emacs-x86_64-10_9               0x0000000100139792 Ffuncall + 1202
51  Emacs-x86_64-10_9               0x0000000100171e3b exec_byte_code + 2331
52  Emacs-x86_64-10_9               0x0000000100139569 Ffuncall + 649
53  Emacs-x86_64-10_9               0x0000000100139cad call1 + 45
54  Emacs-x86_64-10_9               0x00000001000bc66e command_loop_1 + 3518
55  Emacs-x86_64-10_9               0x0000000100137ecb internal_condition_case + 251
56  Emacs-x86_64-10_9               0x00000001000cd13e command_loop_2 + 62
57  Emacs-x86_64-10_9               0x0000000100137863 internal_catch + 243
58  Emacs-x86_64-10_9               0x00000001000bae7d recursive_edit_1 + 221
59  Emacs-x86_64-10_9               0x00000001000bb02c Frecursive_edit + 236
60  Emacs-x86_64-10_9               0x00000001000b9c7c main + 5836
61  libdyld.dylib                   0x00007fff87dad5c9 start + 1

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib          0x00007fff92d3022e kevent64 + 10
1   libdispatch.dylib               0x00007fff8ec60a6a _dispatch_mgr_thread + 52

Thread 2:
0   libsystem_kernel.dylib          0x00007fff92d2f946 __workq_kernreturn + 10
1   libsystem_pthread.dylib         0x00007fff874c04a1 start_wqthread + 13

Thread 3:
0   libsystem_kernel.dylib          0x00007fff92d2f946 __workq_kernreturn + 10
1   libsystem_pthread.dylib         0x00007fff874c04a1 start_wqthread + 13

Thread 4:
0   libsystem_kernel.dylib          0x00007fff92d2f3f6 __select + 10
1   com.apple.Foundation            0x00007fff90d15b7a __NSThread__main__ + 1345
2   libsystem_pthread.dylib         0x00007fff874c22fc _pthread_body + 131
3   libsystem_pthread.dylib         0x00007fff874c2279 _pthread_start + 176
4   libsystem_pthread.dylib         0x00007fff874c04b1 thread_start + 13

Thread 5:
0   libsystem_kernel.dylib          0x00007fff92d2f946 __workq_kernreturn + 10
1   libsystem_pthread.dylib         0x00007fff874c04a1 start_wqthread + 13

Thread 6:
0   libsystem_kernel.dylib          0x00007fff92d2a52e mach_msg_trap + 10
1   libsystem_kernel.dylib          0x00007fff92d2969f mach_msg + 55
2   com.apple.CoreFoundation        0x00007fff868deb14 __CFRunLoopServiceMachPort + 212
3   com.apple.CoreFoundation        0x00007fff868ddfdb __CFRunLoopRun + 1371
4   com.apple.CoreFoundation        0x00007fff868dd838 CFRunLoopRunSpecific + 296
5   com.apple.AppKit                0x00007fff8d9a07a7 _NSEventThread + 137
6   libsystem_pthread.dylib         0x00007fff874c22fc _pthread_body + 131
7   libsystem_pthread.dylib         0x00007fff874c2279 _pthread_start + 176
8   libsystem_pthread.dylib         0x00007fff874c04b1 thread_start + 13

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000006  rcx: 0x00007fff5fbfd038  rdx: 0x0000000000000000
  rdi: 0x0000000000014d9f  rsi: 0x0000000000000006  rbp: 0x00007fff5fbfd060  rsp: 0x00007fff5fbfd038
   r8: 0x000000000000007f   r9: 0x000000010120a990  r10: 0x0000000000000000  r11: 0x0000000000000206
  r12: 0x000000010053b720  r13: 0x000000010053b6c0  r14: 0x0000000000000028  r15: 0x0000000000000020
  rip: 0x00007fff92d2ec7e  rfl: 0x0000000000000206  cr2: 0x000000007a69ea50

Logical CPU:     0
Error Code:      0x02000025
Trap Number:     133
vkz commented 9 years ago

For more infos on how debugging emacs see M-x view-emacs-debugging (C-h C-d)

I'll have another go at debugging a bit later.

thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

Isn't there directions to install gdb in Mac somewhere ?
Would be great you run your crashing emacs inside gdb, starting emacs
from the src/ directory, then running bt and/or xbacktrace would give us
precious informations.

There're and I followed them. For whatever reason the codesigning doesn't seem to work for me. My guess is I need to reboot, which I'd rather avoid for now - too much in the works and it'd be a major disruption. I did however collect the backtrace at crash-site in lldb

  • see an earlier post above. I doubt GDB would give any more information.

Yes it will, with xbacktrace if gdb runs in src/. The point is to get detailed infos on all Ffuncall frames.

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

8 Emacs-x86_64-10_9 0x00000001000c1ac2 detect_input_pending_run_timers + 114

(defmacro helm--maybe-use-while-no-input (&rest body) "Wrap BODY in helm-while-no-input' unless initializing a remote connection." (declare (debug t) (indent 0)) (progn ,@body))

Can you eval this form and try to reproduce ?

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

vkz commented 9 years ago

@thierryvolpiatto

Yes it will, with xbacktrace if gdb runs in src/. The point is to get detailed infos on all Ffuncall frames.

argh, so far it's been nothing but pain. When run from src/ it wouldn't pick up the symbol table so loading .gdbinit fails. My guess is it expects Emacs built with GCC and particular CFLAGS="-Og -g3". Mine is built with Homebrew defaults therefore CLANG. Tried installing GCC-4.9 and compiling with that but so far it stumbles on what looks like some specific Obj-C stuff:

checking for AppKit/AppKit.h... no
configure: error: `--with-ns' was specified, but the include
  files are missing or cannot be compiled.

I'm re-installing GCC with --all-languages but am not optimistic

vkz commented 9 years ago

@thierryvolpiatto

Can you eval this form and try to reproduce ?

eval'ing defmacro didn't make any difference. Still crashing on the same input

vkz commented 9 years ago

nah, recompiling GCC-4.9 did not help and building Emacs without --cocoa may not even reproduce this behavior. If anyone knows how to get GCC on a Mac that just works and eats Obj-C stuff that OS X expects it to handle, pls advise. I think XCode installs GCC somewhere but /usr/bin/gcc seems to simply point to clang. Dunno how to proceed unfortunately

vkz commented 9 years ago

so a more general question then is how does one build a standalone GUI Emacs with GCC on a Mac? Ideas?

vkz commented 9 years ago

oh well, building with gcc-4.9 and no --cocoa doesn't compile either. Bunch of errors in the log and seems it expects clang:

conftest.c:31:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before string constant
      error "not clang";
            ^

Unless someone more knowledgable can step in and guide me through how to build Emacs with gcc with debug info on a Mac I have to give up for now :(

vkz commented 9 years ago

alright, I managed to build Emacs with nextstep support by pulling official git-repo and basically by temporarily halting I am an idiot mode. I can and do now run Emacs under gdb with .gdbinit and all symbol tables properly loaded (I think). Looking through view-emacs-debugging I couldn't figure a good way of passing control to gdb other than set stop_character = 36. So typing $ halts Emacs and sends me to debugger. Unfortunately, setting br at Fsignal turned out a horrible idea, cause this signal just flies around non-stop. Here's where I'm at having executed helm-locate-library with pattern that starts with j followed by $:

(gdb) bt
#0  0x00007fff99de6c7e in ?? () from /usr/lib/system/libsystem_kernel.dylib
#1  0x0000000100159007 in sys_suspend () at sysdep.c:450
#2  0x000000010013ba6d in kbd_buffer_store_event_hold (event=0x7fff5fbf64d8, 
    hold_quit=0x7fff5fbf6550) at keyboard.c:3634
#3  0x00000001002aaa7d in -[EmacsView insertText:] (self=0x10b449250, _cmd=0x7fff9ac798ab, 
    aString=0x10d3806a0) at nsterm.m:5443
#4  0x00007fff9ab14bab in -[NSTextInputContext(NSInputContext_WithCompletion) insertText:replacementRange:completionHandler:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#5  0x00007fff9ab0cd9a in __55-[NSTextInputContext handleTSMEvent:completionHandler:]_block_invoke_2242 () from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#6  0x00007fff9ab097dd in -[NSTextInputContext do_HandleTSMEvent_insertFixLenTextLoop:whileCondition:dispatchWorkEach:afterEachInsertText:continuation:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#7  0x00007fff9ab09a8e in -[NSTextInputContext tryHandleTSMEvent_insertFixLenText_withContext:dispatchCondition:setupForDispatch:nestedWorkaroundCondition:nestedWorkaroundDispatchWork:loopCondition:dispatchWorkEach:afterEachInsertText:continuation:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#8  0x00007fff9ab0c7f6 in __55-[NSTextInputContext handleTSMEvent:completionHandler:]_block_invoke174 () from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#9  0x00007fff9ab150bf in -[NSTextInputContext(NSInputContext_WithCompletion) hasMarkedTextWithCompletionHandler:] () from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#10 0x00007fff9ab0b8a4 in __55-[NSTextInputContext handleTSMEvent:completionHandler:]_block_invoke_2 () from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#11 0x00007fff9ab095f8 in -[NSTextInputContext tryHandleTSMEvent_HasMarkedText_withDispatchCondition:dispatchWork:continuation:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#12 0x00007fff9ab0b600 in -[NSTextInputContext handleTSMEvent:completionHandler:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#13 0x00007fff9a4f37ee in _NSTSMEventHandler ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#14 0x00007fff92e4932c in DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#15 0x00007fff92e4876e in SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#16 0x00007fff92e485e2 in SendEventToEventTargetWithOptions ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#17 0x00007fff9305b68c in SendTSMEvent_WithCompletionHandler ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#18 0x00007fff9305bb8c in __SendUnicodeTextAEToUnicodeDoc_WithCompletionHandler_block_invoke
    ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#19 0x00007fff9305be46 in __SendFilterTextEvent_WithCompletionHandler_block_invoke ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#20 0x00007fff9305b6e0 in SendTSMEvent_WithCompletionHandler ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#21 0x00007fff9305b9cf in SendFilterTextEvent_WithCompletionHandler ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#22 0x00007fff93058d41 in SendUnicodeTextAEToUnicodeDoc_WithCompletionHandler ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#23 0x00007fff9305d649 in __utDeliverTSMEvent_WithCompletionHandler_block_invoke_2 ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#24 0x00007fff9305d518 in __utDeliverTSMEvent_WithCompletionHandler_block_invoke ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#25 0x00007fff930587bd in TSMKeyEvent_WithCompletionHandler ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#26 0x00007fff930622f0 in __TSMProcessRawKeyEventWithOptionsAndCompletionHandler_block_invoke_4 ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#27 0x00007fff930621e6 in __TSMProcessRawKeyEventWithOptionsAndCompletionHandler_block_invoke_3 ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#28 0x00007fff93062022 in __TSMProcessRawKeyEventWithOptionsAndCompletionHandler_block_invoke_2 ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#29 0x00007fff93061ea5 in __TSMProcessRawKeyEventWithOptionsAndCompletionHandler_block_invoke
    ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#30 0x00007fff93061caf in TSMProcessRawKeyEventWithOptionsAndCompletionHandler ()
   from /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
#31 0x00007fff9ab13226 in __61-[NSTextInputContext _handleEvent:options:completionHandler:]_block_invoke945 () from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#32 0x00007fff9ab12762 in -[NSTextInputContext tryTSMProcessRawKeyEvent:dispatchCondition:setupForDispatch:furtherCondition:dispatchWork:continuation:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#33 0x00007fff9ab12d95 in -[NSTextInputContext _handleEvent:options:completionHandler:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#34 0x00007fff9a4f302e in -[NSTextInputContext handleEvent:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#35 0x00007fff9a4d2c7d in -[NSView interpretKeyEvents:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#36 0x00000001002aa721 in -[EmacsView keyDown:] (self=0x10b449250, _cmd=0x7fff9ac562b7, 
    theEvent=0x10c711fa0) at nsterm.m:5381
#37 0x00007fff9aa159f6 in -[NSWindow _reallySendEvent:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#38 0x00007fff9a4a250c in -[NSWindow sendEvent:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#39 0x00007fff9a454811 in -[NSApplication sendEvent:] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#40 0x00000001002a7982 in -[EmacsApp sendEvent:] (self=0x102a15300, _cmd=0x7fff9ac466a9, 
    theEvent=0x10c711fa0) at nsterm.m:4648
#41 0x00007fff9a2e0e98 in -[NSApplication run] ()
   from /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
#42 0x00000001002a734a in -[EmacsApp run] (self=0x102a15300, _cmd=0x7fff9ac4bfc4)
    at nsterm.m:4507
#43 0x00000001002b7f32 in ns_read_socket (terminal=0x105009c48, hold_quit=0x7fff5fbf6550)
    at nsterm.m:3652
#44 0x000000010013661d in gobble_input () at keyboard.c:6850
#45 0x000000010013c835 in get_input_pending (flags=2) at keyboard.c:6771
#46 0x000000010014160d in Finput_pending_p (check_timers=4320145466) at keyboard.c:9940
#47 0x00000001001f2764 in Ffuncall (nargs=1, args=0x7fff5fbf66d8) at eval.c:2811
#48 0x000000010024c980 in exec_byte_code (bytestr=4341424433, vector=4347042501, 
    maxdepth=16, args_template=4320145466, nargs=0, args=0x0) at bytecode.c:916
#49 0x00000001001f3c81 in funcall_lambda (fun=4328855477, nargs=0, arg_vector=0x7fff5fbf6f58)
    at eval.c:3044
#50 0x00000001001f298c in Ffuncall (nargs=1, args=0x7fff5fbf6f50) at eval.c:2860
#51 0x00000001001f1e45 in Fapply (nargs=2, args=0x7fff5fbf6f50) at eval.c:2293
#52 0x00000001001f262a in Ffuncall (nargs=3, args=0x7fff5fbf6f48) at eval.c:2792
#53 0x000000010024c980 in exec_byte_code (bytestr=4299738641, vector=4299738693, 
    maxdepth=16, args_template=4320145466, nargs=0, args=0x0) at bytecode.c:916
#54 0x000000010024bbbf in Fbyte_code (bytestr=4299738641, vector=4299738693, maxdepth=16)
    at bytecode.c:482
#55 0x00000001001ed675 in eval_sub (form=4299738614) at eval.c:2187
#56 0x00000001001f03f1 in internal_lisp_condition_case (var=4395632298, bodyform=4299738614, 
    handlers=4299738734) at eval.c:1317
#57 0x000000010024de97 in exec_byte_code (bytestr=4299738345, vector=4299738381, 
    maxdepth=20, args_template=4320145466, nargs=0, args=0x0) at bytecode.c:1162
#58 0x00000001001f3c81 in funcall_lambda (fun=4299738301, nargs=1, arg_vector=0x7fff5fbf7eb8)
    at eval.c:3044
#59 0x00000001001f298c in Ffuncall (nargs=2, args=0x7fff5fbf7eb0) at eval.c:2860
#60 0x00000001001f3259 in call1 (fn=4345308874, arg1=4347042725) at eval.c:2610
#61 0x000000010013d077 in timer_check_2 (timers=4540389718, idle_timers=4320145466)
    at keyboard.c:4514
#62 0x000000010013c937 in timer_check () at keyboard.c:4581
#63 0x00000001002593d2 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, 
    do_display=true, wait_for_cell=4320145466, wait_proc=0x0, just_wait_proc=0)
    at process.c:4388
#64 0x000000010000899e in sit_for (timeout=120, reading=true, display_option=1)
    at dispnew.c:5861
#65 0x0000000100137e78 in read_char (commandflag=1, map=4539763926, prev_event=4320145466, 
    used_mouse_menu=0x7fff5fbf8d9f, end_time=0x0) at keyboard.c:2809
#66 0x0000000100133977 in read_key_sequence (keybuf=0x7fff5fbf8f90, bufsize=30, 
    prompt=4320145466, dont_downcase_last=false, can_return_switch_frame=true, 
    fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9088
#67 0x00000001001326e8 in command_loop_1 () at keyboard.c:1452
#68 0x00000001001f05cc in internal_condition_case (bfun=0x100132220 <command_loop_1>, 
    handlers=4320191562, hfun=0x10014c680 <cmd_error>) at eval.c:1348
#69 0x000000010014c579 in command_loop_2 (ignore=4320145466) at keyboard.c:1177
#70 0x00000001001efc04 in internal_catch (tag=4320200298, func=0x10014c550 <command_loop_2>, 
    arg=4320145466) at eval.c:1112
#71 0x0000000100131730 in command_loop () at keyboard.c:1148
#72 0x0000000100131664 in recursive_edit_1 () at keyboard.c:777
#73 0x0000000100179956 in read_minibuf (map=4509698262, initial=4320145466, 
    prompt=4513451793, expflag=false, histvar=4320212282, histpos=0, defalt=4320145466, 
    allow_props=false, inherit_input_method=true) at minibuf.c:674
#74 0x0000000100178ae9 in Fread_from_minibuffer (prompt=4513451793, 
    initial_contents=4320145466, keymap=4509698262, read=4320145466, hist=4320145466, 
    default_value=4320145466, inherit_input_method=4320145514) at minibuf.c:957
#75 0x00000001001f28ce in Ffuncall (nargs=8, args=0x7fff5fbf96e0) at eval.c:2837
#76 0x000000010024c980 in exec_byte_code (bytestr=4513446641, vector=4360057141, 
    maxdepth=92, args_template=7196, nargs=7, args=0x7fff5fbf9e40) at bytecode.c:916
#77 0x00000001001f38a4 in funcall_lambda (fun=4360057597, nargs=7, arg_vector=0x7fff5fbf9e08)
    at eval.c:2978
#78 0x00000001001f298c in Ffuncall (nargs=8, args=0x7fff5fbf9e00) at eval.c:2860
#79 0x000000010024c980 in exec_byte_code (bytestr=4341660881, vector=4358227565, 
    maxdepth=36, args_template=0, nargs=0, args=0x7fff5fbfa518) at bytecode.c:916
#80 0x00000001001f38a4 in funcall_lambda (fun=4358227901, nargs=0, arg_vector=0x7fff5fbfa518)
    at eval.c:2978
#81 0x00000001001f298c in Ffuncall (nargs=1, args=0x7fff5fbfa510) at eval.c:2860
#82 0x00000001001ed4c3 in eval_sub (form=4526877606) at eval.c:2154
#83 0x00000001001f03f1 in internal_lisp_condition_case (var=4505747506, bodyform=4526877606, 
    handlers=4526875702) at eval.c:1317
#84 0x000000010024de97 in exec_byte_code (bytestr=4504195041, vector=4358226821, 
    maxdepth=76, args_template=0, nargs=0, args=0x7fff5fbfaef8) at bytecode.c:1162
#85 0x00000001001f38a4 in funcall_lambda (fun=4358227181, nargs=0, arg_vector=0x7fff5fbfaef8)
    at eval.c:2978
#86 0x00000001001f298c in Ffuncall (nargs=1, args=0x7fff5fbfaef0) at eval.c:2860
#87 0x00000001001ed4c3 in eval_sub (form=4526877414) at eval.c:2154
#88 0x00000001001efc04 in internal_catch (tag=4320200298, func=0x1001eced0 <eval_sub>, 
    arg=4526877414) at eval.c:1112
#89 0x000000010024da8c in exec_byte_code (bytestr=4504195553, vector=4312520773, 
    maxdepth=100, args_template=9216, nargs=9, args=0x7fff5fbfb8d0) at bytecode.c:1097
#90 0x00000001001f38a4 in funcall_lambda (fun=4312520925, nargs=9, arg_vector=0x7fff5fbfb888)
    at eval.c:2978
#91 0x00000001001f298c in Ffuncall (nargs=10, args=0x7fff5fbfb880) at eval.c:2860
#92 0x00000001001f22de in Fapply (nargs=2, args=0x7fff5fbfba60) at eval.c:2350
#93 0x00000001001f262a in Ffuncall (nargs=3, args=0x7fff5fbfba58) at eval.c:2792
#94 0x000000010024c980 in exec_byte_code (bytestr=4504193201, vector=4312519285, 
    maxdepth=44, args_template=512, nargs=9, args=0x7fff5fbfc178) at bytecode.c:916
#95 0x00000001001f38a4 in funcall_lambda (fun=4312519517, nargs=9, arg_vector=0x7fff5fbfc178)
    at eval.c:2978
#96 0x00000001001f298c in Ffuncall (nargs=10, args=0x7fff5fbfc170) at eval.c:2860
#97 0x00000001001f22de in Fapply (nargs=2, args=0x7fff5fbfc350) at eval.c:2350
#98 0x00000001001f262a in Ffuncall (nargs=3, args=0x7fff5fbfc348) at eval.c:2792
#99 0x000000010024c980 in exec_byte_code (bytestr=4504193201, vector=4312519285, 
    maxdepth=44, args_template=512, nargs=4, args=0x7fff5fbfca70) at bytecode.c:916
#100 0x00000001001f38a4 in funcall_lambda (fun=4312519517, nargs=4, 
    arg_vector=0x7fff5fbfca70) at eval.c:2978
#101 0x00000001001f298c in Ffuncall (nargs=5, args=0x7fff5fbfca68) at eval.c:2860
#102 0x000000010024c980 in exec_byte_code (bytestr=4515420305, vector=4379640869, 
    maxdepth=68, args_template=0, nargs=0, args=0x7fff5fbfd208) at bytecode.c:916
#103 0x00000001001f38a4 in funcall_lambda (fun=4360177669, nargs=0, 
    arg_vector=0x7fff5fbfd208) at eval.c:2978
#104 0x00000001001f298c in Ffuncall (nargs=1, args=0x7fff5fbfd200) at eval.c:2860
#105 0x00000001001ecb2a in apply1 (fn=4318258370, arg=4320145466) at eval.c:2577
#106 0x00000001001e957d in Fcall_interactively (function=4318258370, record_flag=4345603018, 
    keys=4345303685) at callint.c:378
#107 0x00000001001f27ba in Ffuncall (nargs=4, args=0x7fff5fbfd698) at eval.c:2818
#108 0x000000010024c980 in exec_byte_code (bytestr=4299299785, vector=4299299821, 
    maxdepth=52, args_template=4100, nargs=2, args=0x7fff5fbfddf8) at bytecode.c:916
#109 0x00000001001f38a4 in funcall_lambda (fun=4299299741, nargs=2, 
    arg_vector=0x7fff5fbfdde8) at eval.c:2978
#110 0x00000001001f298c in Ffuncall (nargs=3, args=0x7fff5fbfdde0) at eval.c:2860
#111 0x000000010024c980 in exec_byte_code (bytestr=4504654785, vector=4316957069, 
    maxdepth=180, args_template=0, nargs=0, args=0x7fff5fbfe628) at bytecode.c:916
#112 0x00000001001f38a4 in funcall_lambda (fun=4316957653, nargs=0, 
    arg_vector=0x7fff5fbfe628) at eval.c:2978
#113 0x00000001001f298c in Ffuncall (nargs=1, args=0x7fff5fbfe620) at eval.c:2860
#114 0x00000001001ecb2a in apply1 (fn=4318534914, arg=4320145466) at eval.c:2577
#115 0x00000001001e957d in Fcall_interactively (function=4318534914, record_flag=4320145466, 
    keys=4345303685) at callint.c:378
#116 0x00000001001f27ba in Ffuncall (nargs=4, args=0x7fff5fbfeab8) at eval.c:2818
#117 0x000000010024c980 in exec_byte_code (bytestr=4299299785, vector=4299299821, 
    maxdepth=52, args_template=4100, nargs=1, args=0x7fff5fbff210) at bytecode.c:916
#118 0x00000001001f38a4 in funcall_lambda (fun=4299299741, nargs=1, 
    arg_vector=0x7fff5fbff208) at eval.c:2978
#119 0x00000001001f298c in Ffuncall (nargs=2, args=0x7fff5fbff200) at eval.c:2860
#120 0x00000001001f3259 in call1 (fn=4345312618, arg1=4318534914) at eval.c:2610
#121 0x0000000100132b77 in command_loop_1 () at keyboard.c:1559
#122 0x00000001001f05cc in internal_condition_case (bfun=0x100132220 <command_loop_1>, 
    handlers=4320191562, hfun=0x10014c680 <cmd_error>) at eval.c:1348
#123 0x000000010014c579 in command_loop_2 (ignore=4320145466) at keyboard.c:1177
#124 0x00000001001efc04 in internal_catch (tag=4345316202, 
    func=0x10014c550 <command_loop_2>, arg=4320145466) at eval.c:1112
#125 0x000000010013179b in command_loop () at keyboard.c:1156
#126 0x0000000100131664 in recursive_edit_1 () at keyboard.c:777
#127 0x0000000100131947 in Frecursive_edit () at keyboard.c:848
#128 0x000000010012f93c in main (argc=4, argv=0x7fff5fbff868) at emacs.c:1642

Lisp Backtrace:
"input-pending-p" (0x5fbf66e0)
"auto-revert-buffers" (0x5fbf6f58)
"apply" (0x5fbf6f50)
"byte-code" (0x5fbf7640)
"timer-event-handler" (0x5fbf7eb8)
"read-from-minibuffer" (0x5fbf96e8)
"helm-read-pattern-maybe" (0x5fbf9e08)
0x3c547b8 PVEC_COMPILED
"funcall" (0x5fbfa510)
0x3c544e8 PVEC_COMPILED
"funcall" (0x5fbfaef0)
"helm-internal" (0x5fbfb888)
"apply" (0x5fbfba60)
"helm" (0x5fbfc178)
"apply" (0x5fbfc350)
"helm" (0x5fbfca70)
"helm-locate-library" (0x5fbfd208)
"call-interactively" (0x5fbfd6a0)
"command-execute" (0x5fbfdde8)
"helm-M-x" (0x5fbfe628)
"call-interactively" (0x5fbfeac0)
"command-execute" (0x5fbff208)
(gdb)

@thierryvolpiatto what should I be looking at? What would you want to see here?

thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

@thierryvolpiatto what should I be looking at? What would you want to see here?

Well the lisp backtrace is quite interesting, I wonder why auto-revert which calls input-pending-p (which can be evil) is running here.

What is the cause of the crash though, just the first lines of gdb when emacs crash.

Did you run xbacktrace to get lisp backtrace ?

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

vkz commented 9 years ago

doesn't crash under (gdb) just stalls horribly. It does crash not under (gdb) if I type quickly enough.

Did you run xbacktrace to get lisp backtrace ?

not specifically, but I see bt is redefined in .gdbinit to autorun xbacktrace

vkz commented 9 years ago

right, definitely wouldn't crash under (gdb) but it freezes for a loooooooong time so any following key-strokes arrive after about a minute. C-g multiple times, more waiting and back to normal. Works fine after that. Doing the entire thing again goes exactly the same way

vkz commented 9 years ago

Well the lisp backtrace is quite interesting, I wonder why auto-revert which calls input-pending-p (which can be evil) is running here.

Grep shows that helm-plugin.el sets (auto-revert-mode 1) if that is of any help.

I also have the following settings loaded:


;; Auto refresh buffers
(global-auto-revert-mode 1)

;; Also auto refresh dired, but be quiet about it
(setq global-auto-revert-non-file-buffers t)
(setq auto-revert-verbose nil)
thierryvolpiatto commented 9 years ago

vkz notifications@github.com writes:

Well the lisp backtrace is quite interesting, I wonder why auto-revert
which calls input-pending-p (which can be evil) is running here.

Grep shows that helm-plugin.el sets (auto-revert-mode 1) if that is of any help.

Not enabled in our case and rarely (never) used anyway.

I also have the following settings loaded:

;; Auto refresh buffers (global-auto-revert-mode 1)

;; Also auto refresh dired, but be quiet about it (setq global-auto-revert-non-file-buffers t) (setq auto-revert-verbose nil)

Without those settings what is happening ?

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

tuhdo commented 9 years ago

@vkz I reinstalled my Mac OS X again and upgraded it to Yosemite. While I did have a crash using Emacs for Mac OS X (if you don't know, look it up on Google), using emacs-mac-port, I had no issue. It only had a brief freeze when I jammed many keys at once, but as soon as I pressed C-g, it went back to normal. I suggest you should give emacs-mac-port a try, and install it with brew.

vkz commented 9 years ago

@tuhdo emacs-mac-port crashes immediately as I type "j" when helm-locate-library. I'm officially out of Emacs 24 versions that work :)

tuhdo commented 9 years ago

@vkz Are you sure you ran correct Emacs binary? Someone confirmed it work in this issue: https://github.com/bbatsov/projectile/issues/600 (scroll at the end). After installing emacs-mac-port, you need to run it in /usr/local/Cellar/emacs-mac/emacs-24.4-mac-5.2/bin/, not just emacs in your terminal. If you want to run GUI, make an alias to your Application directory, or use File Inder and browse to there, then double click. The correct version should have GNU buffalo icon, not Emacs icon.

tuhdo commented 9 years ago

@vkz People using Spacemacs also solved this issue with emacs-mac-port. See it here: https://github.com/syl20bnr/spacemacs/issues/432.

vkz commented 9 years ago

@tuhdo @thierryvolpiatto oh wow, so it's not just j. Beginning pattern in helm-locate-library with any of these keys crashes Emacs:

Qwerty(physical) -> Dvorak

z -> ; x -> q c -> j

q -> ' w -> , ] -> = = -> ]

And maybe others. Incidentally, I tried switching to Qwerty layout and starting patters with the problematic keys e.g. typing keys ; q j ' , = ] which are obviously different physical keys in Qwerty but have the same key-codes and they do crash Emacs too. Which leads me to believe that it's not a signal problem, not a hardware issue but rather likely something at Elisp level parsing key-codes and crashing on particular key-codes.