Crash on C-g after C-x

[k-ode]

Hi! Thanks for a great project, it's super useful.

However, I'm having some issues with frequent crashes on Windows with Emacs 25. If I press C-x followed by C-g (to abort the sequence), which-key almost always makes Emacs hang and become unresponsive.

This is on Windows 8 with Emacs 25.0.94.2.

Please let me know if you need to me to provide more information, or anything else I can do to help.

[justbur]

Hi, I haven't experienced this and I have a similar setup. What settings do you have for which-key and have you tried reproducing with emacs -Q?

[k-ode]

I don't experience the same crashes with emacs -Q. I've narrowed the problem down in my config, and it seems it's because I use a custom font.

(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(default ((t (:family "Roboto Mono" :foundry "outline" :slant normal :weight normal :height 98 :width normal :spacing c)))))

If i run my config with this code commented out, I have no issues. But if I evaluate this, which-key crashes after a couple of C-x C-g.

I get this issue regardless of which-key settings, but it does seem to trigger more often if the idle delay option is lower.

(setq which-key-idle-delay 0.4)

[justbur]

Try the new option in commit eb4a6f6

(setq which-key-allow-imprecise-window-fit t)

In my tests it appears to me that for some reason that font slows down the calculation of window sizes. My emacs seemed noticeably laggy when I used that font. which-key was lagging in one particular area and this variable allows you to bypass that calculation. It shouldn't make a huge difference, but let me know if you notice problems.

[k-ode]

Sadly, it doesn't seem to help much.

It's a really weird problem. It works fine with most fonts, but I've also seen this with Anonymous Pro.

[k-ode]

Feels more like an upstream issue though.

[justbur]

Hm, I don't know what to say. If you can profile which-key on your computer we might be able to narrow it down, but I'm not using windows at the moment, so I'm not sure what I can do on my side.

[k-ode]

Sorry for the delay. I've tried profiling this, but I can't really see a difference between using a "normal" font and a font that causes issues. Do you still want to see the result?

As you said, this feels more like a general issue with Emacs using those fonts. I'll prepare a bug report to Emacs.

Thanks for looking into this!

[justbur]

Sure, I'll take a look, but it does sound like an upstream issue. What version of emacs are you on now? Have you tried 25.1?

[byronsanchez]

@kimgronqvist - Quick question- was there ever a response from upstream and a place where this is currently being discussed? I have the exact same issue, except I'm using the font Ubuntu Mono (powerline version) on Windows with native Emacs v25.0.90.3.

[k-ode]

@byronsanchez I believe this is the same bug: https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-10/msg00334.html

The workaround is supposed to be setting inhibit-compacting-font-caches to nil. I'm unsure if there is a release with this fix yet though, and I havn't personally tested it yet.

[justbur]

Thanks for the pointer @kimgronqvist

[ylluminarious]

@justbur I'm having the same issue as well. I was actually relieved to find this thread; this bug was driving me crazy and I was afraid that I was the only one. My current version info is as follows:

GNU Emacs 25.3.12 (x86_64-apple-darwin17.5.0, Carbon Version 158 AppKit 1561.4) of 2018-05-14

I.e., I'm on GNU Emacs 25.3 using the Emacs Mac Port by Yamamoto Mitsuharu. I'm also on macOS 10.13.5. It is possible that this issue is gone in Emacs 26, but I haven't used Emacs 26 yet and I can't remember reading anything about this bug in the NEWS file.

[justbur]

@ylluminarious Can you reproduce it with another build of emacs like this one?

[ylluminarious]

@justbur I'll try. I'll let you know what I find.

[ylluminarious]

@justbur Still happens on Emacs 26. Although, it is quite mitigated by using the new global-display-line-numbers-mode instead of global-linum-mode. I think that linum-mode was the bottleneck causing Emacs to hang in the first place.

I noticed previously that every time this issue happened, linum-mode would be turned on in buffers where it was supposed to be off. In Emacs 26, the same sort of thing happens; once Emacs hangs, there are line numbers in buffers where they were supposed to be off. But the hang doesn't last as long and it's not as severe, I guess because display-line-numbers-mode is implemented in C and is much faster than linum-mode.

[justbur]

@ylluminarious I just tried getting emacs to crash with global-linum-mode on, but I can't. I'm using emacs26 right now, too.

[ylluminarious]

@justbur It seems to happen sporadically, not consistently. Perhaps try it out at various intervals while doing different things with Emacs. I haven't pinned down the all of the exact circumstances which cause the hang.

[justbur]

@ylluminarious I'm not optimistic about finding this one on my own. Maybe you could seek help from emacs developers?

[Compro-Prasad]

Does setting inhibit-compacting-font-caches to nil help?

[ylluminarious]

@Compro-Prasad I'm not sure... I've been running Emacs with it set as such for about a day or two and I haven't noticed the hang yet, but that doesn't mean it won't occur at some point in the future. However, given that I haven't seen it occur yet, it suggests in my mind that perhaps this variable and this issue are related. Emacs does seem to be consuming somewhat more memory than before after setting this variable... although this is to be expected as it says in the variable's docstring as well as the fact that I have lots of things going on in Emacs.

[ylluminarious]

@Compro-Prasad I've been running with that setting for the better part of a week now, so I'd say yes. Setting inhibit-compacting-font-caches to nil does seem to help. Ping @justbur

[justbur]

@ylluminarious Sounds good, but I'm not sure I should change anything since it seems specific to a few users. I'd certainly keep this issue around, of course.

[Compro-Prasad]

@justbur Better mention in the README

[justbur]

@Compro-Prasad done

[zwass]

I've been able to reproduce this repeatedly with Emacs 26.3 on macOS. To consistently reproduce, I open a 307K file and then do C-x C-g a few times. The trick is timing it to hit C-g while the window is opening. This only happens in GUI Emacs.

Setting inhibit-compacting-font-caches does not help. Changing to a different font does not help.

Using an empty emacs config and only loading which-key does seem to resolve the problem. My default configuration uses Doom Emacs. It's not clear what may be interacting.

I noticed another user reporting the same issue on Reddit: https://www.reddit.com/r/emacs/comments/g1uk3c/emacs_gui_freezes/

[Compro-Prasad]

Themes may cause some problems. Try loading the doom theme you use in an empty Emacs config. Try adding modeline if the theme doesn't cause the issue.

[zwass]

The issue appears to only occur with the modeline that Doom uses by default. I switch to telephone-line and can no longer reproduce.

[zwass]

It seems that setting which-key-allow-imprecise-window-fit may resolve this issue. It does unfortunately cause #231 to occur, but that is much better than a full hang of emacs.

[zwass]

FWIW which-key-allow-imprecise-window-fit does not entirely resolve the issue, but it does significantly reduce the frequency of it occurring.

[hyl0327]

I'm also having this problem, and I'm using Doom Emacs on macOS.

But unlike what @zwass mentioned, I could reproduce this even without enabling Doom's modeline module. In addition, it doesn't even have to be in a big file (307k); it could happen anywhere, at anytime.

My way of reproducing this is basically the same as @zwass's:

1. Press C-x
2. Wait a moment, and try to press C-g just before which-key window pops up
3. It could hang here; try again if it doesn't

And I was able to observe two different visual states when it hangs (they seem to show up randomly):

1. It hangs, with minibuffer showing C-x-
2. It hangs, with minibuffer showing C-x- (1 of 4) [C-h paging/help]

After it hangs, it seems only kill can help.

I'm quite new to ELisp programming, and don't really have any good idea how to debug this ... But I'm willing to help anyway. Please let me know if there's anything I can help.

Thanks.

[ksalman]

I am using Doom Emacs on OSX (Catalina), and I see the same issue as @hyl0327 , though my files are pretty small.

[NeCkEr]

experiencing the same problem that @hyl0327 described

[justbur]

Based on these reports, this still seems related to something doom is doing. If there's something doom is doing to cause this, it would be very helpful towards resolving the issue, but I have neither the time nor the interest in digging through the doom configuration to figure out what's wrong.

If it's not a doom issue, it should be reproducible from vanilla emacs (emacs -Q) with which-key loaded of course. If someone can figure out a way to reliably reproduce the issue from that setup, I will look into it. I have not been able to reproduce it from my personal setup.

[brianreidy]

I was able to replicate with vanila emacs with doom theme and doom modeline installed.