helm-projectile crashes/breaks emacs on Mac OS X

[smolyn]

Ok, I realize this isn't necessarily a Helm/Projectile bug. However, in some ways I'm filing this perhaps for help with how to properly present this bug to Emacs developers.

Emacs on Mac OS X in windowed mode (using nsterm.m) will crash (in 24.4) or break (in 25) when using helm-projectile with a largish project (28k files).

There are several bugs filed with Emacs (one by me),
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18345
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19531

The Emacs maintainers apparently don't realize there are lisp projects out there, so it looks like there is a bit of pushback.
Unfortunately I don't have time (or knowledge) of how to reproduce this bug. I'm pretty sure it has something to do with the async aspects of populating/updating the minibuffer with the fuzzy search items.
This is unfortunately making helm-projectile harder for me to use, as I have to run emacs in a terminal instead of in windowed mode.
I'm happy to help in any way I can, within the time constraints I have available.

[tuhdo]

What type of VCS does your project use? If it's git, e30k to 50k is no problem. It works even on Windows. Could you paste your Error backtrace? Helm Projectile only reuses the source from Projectile. Could you try with helm-mode disabled and plain projectile-find-file to see if it still crashes. If so, it's probably Emacs's problem.

Edit: no need to paste the backtrace here. I looked at the bug reports.

[tuhdo]

And you should increase memory to be used before garbage collecting, by setting this:

(setq gc-cons-threshold 100000000)

You set the threshold to 100MB and try again if it still crashes.

[smolyn]

Ok with helm-mode disabled, everything works as expected (no crash, no breakage in 25.0.50).

You can see my crash output on this bug thread:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2015-01/msg00112.html

I think it definitely is a bug in Emacs, only made apparent by something helm is doing.

I don't know the best way to get the Emacs team to fix it though, because I'm pretty sure I can't reproduce it without loading all of helm (and it doesn't sound like thats the way they want to debug/test).

[smolyn]

here's the xbacktrace from the crash:
"redisplay_internal (C function)" (0x53dbf0)
"read-from-minibuffer" (0x5fbfc568)
"helm-read-pattern-maybe" (0x5fbfc6a8)
0x1a776850 PVEC_COMPILED
"funcall" (0x5fbfc7d0)
0x1a775928 PVEC_COMPILED
"funcall" (0x5fbfcac0)
"helm-internal" (0x5fbfcd98)
"apply" (0x5fbfcec0)
"helm" (0x5fbfcff8)
"apply" (0x5fbfd120)
"helm" (0x5fbfd260)
"helm-projectile-find-file" (0x5fbfd428)
"projectile-switch-project-by-name" (0x5fbfd4c0)
"let" (0x5fbfd6c0)
0x1a825eb0 Lisp type 6
"apply" (0x5fbfd948)
"helm-funcall-with-source" (0x5fbfda80)
"helm-execute-selection-action-1" (0x5fbfdbb0)
"helm-execute-selection-action" (0x5fbfdcc0)
0x1a66a3b0 PVEC_COMPILED
"funcall" (0x5fbfddf0)
0x1a66a338 PVEC_COMPILED
"funcall" (0x5fbfe0e0)
"helm-internal" (0x5fbfe3b8)
"apply" (0x5fbfe4e0)
"helm" (0x5fbfe618)
"apply" (0x5fbfe740)
"helm" (0x5fbfe880)
"helm-projectile-switch-project" (0x5fbfea48)
0x534268 PVEC_SUBR
"ad-Advice-call-interactively" (0x5fbfed78)
"apply" (0x5fbfee78)
"call-interactively" (0x5fbfefc0)
"command-execute" (0x5fbff0e8)

[tuhdo]

Ok with helm-mode disabled, everything works as expected (no crash, no breakage in 25.0.50).

By working as expected, do you mean stock Projectile commands with Ido or Helm Projectile commands? Unfortunately I deleted my Mac OS X from my hard drive to install Ubuntu recently since I can't stand its window behaviour. I will reinstall it in the future when I got time.

[smolyn]

Stock projectile commands with Ido.

[tuhdo]

Maybe I have you Helm configuration (or better, the whole .emacs.d)?

[tuhdo]

I've tried the recipe in your bug report with aura repo and cannot reproduce it in Ubuntu, I can even fuzzy match in Linux source tree, which has over 30k files. I think this has to do with fuzzy matching in Helm and seems like Emacs on Mac OS could not handle fuzzy matching on large amount of file. Could you please try this:

(setq helm-projectile-fuzzy-match nil)
(require 'helm-projectile)

Add the above code before (helm-projectile-on) to disable fuzzy matching in Helm Projectile than try again. It's likely that in stock Projectile with Ido, you did not use fuzzy matching in Ido.

[tuhdo]

@smolyn Did it crash with fuzzy matching disabled?

[zilvinasu]

The problem for me, with fuzzy matching and gc-cons-threshold increased is when I type some pattern in the field and I reach the part when there are no results to show and adding extra characters to pattern makes no sense, but if I accidentally do, it crashes every time.

[tuhdo]

@zilvinasu Does it crash with fuzzy matching disabled?

[zilvinasu]

@tuhdo It does

[tuhdo]

It does? Could you provide more info:

• Your OS.
• Your Emacs version.
• How large your candidate list is when it crashed?

[zilvinasu]

• Mac OS X 10.10.2
• GNU Emacs 24.4.1
• It is at something like 100 candidates, but when I type any symbol to the existing pattern like "list.html" -> "list.htmlaa" it gives candidates, but it crashes.

[tuhdo]

@zilvinasu Thank for your info.

Could you try this bare Helm command at the root of your project to see if it crashes?

(helm :sources (helm-build-in-buffer-source "test"
                 :data (split-string (shell-command-to-string "git ls-files") "\n")
                 :fuzzy-match t)
      :buffer "*helm test*")

Also, could you save the file list at project root with this command:

git ls-files > file_list.txt

Then run this code:

(with-current-buffer (find-file-noselect "./file_list.txt") 
   (helm :sources (helm-build-sync-source "test" 
                    :candidates (save-match-data (split-string (buffer-string) "\n" t)) 
                    :fuzzy-match t)) 
         :buffer "*helm test*")

to see if it also crashes?