Hello, This is a bit weird to describe so please bear with me. I am using emacs for my day to day editing, and using Spacemacs (http://spacemacs.org/) as a bundle of predefined configurations. Some times, while opening files trough helm I would get a segfault. I took a look in the coredump and also attached gdb to emacs and this is the backtrace: ``` #0 0x00000000004ab2e0 in turn_on_face (f=0xc1c680, face_id=33) at term.c:1895 #1 0x00000000004af432 in tty_write_glyphs (f=, string=, len=) at term.c:767 #2 0x000000000041c2ea in update_frame_line (f=f@entry=0xc1c680, vpos=vpos@entry=29) at dispnew.c:4838 #3 0x000000000041f9e6 in update_frame_1 (f=f@entry=0xc1c680, force_p=force_p@entry=true, inhibit_id_p=, inhibit_id_p@entry=false, set_cursor_p=set_cursor_p@entry=true) at dispnew.c:4540 #4 0x00000000004210fe in update_frame (f=f@entry=0xc1c680, force_p=, force_p@entry=false, inhibit_hairy_id_p=inhibit_hairy_id_p@entry=false) at dispnew.c:3122 #5 0x0000000000452ebc in redisplay_internal () at xdisp.c:14085 #6 0x0000000000454ad5 in redisplay () at xdisp.c:13255 #7 0x00000000004f3d1b in read_char (commandflag=commandflag@entry=1, map=map@entry=28177075, prev_event=0, used_mouse_menu=used_mouse_menu@entry=0x7fffe9ed04db, end_time=end_time@entry=0x0) at keyboard.c:2482 #8 0x00000000004f66f0 in read_key_sequence (keybuf=keybuf@entry=0x7fffe9ed05b0, prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9068 #9 0x00000000004f8216 in command_loop_1 () at keyboard.c:1370 #10 0x0000000000559742 in internal_condition_case (bfun=bfun@entry=0x4f8020 , handlers=handlers@entry=19104, hfun=hfun@entry=0x4eece0 ) at eval.c:1315 #11 0x00000000004ea3fc in command_loop_2 (ignore=ignore@entry=0) at keyboard.c:1112 #12 0x00000000005596e3 in internal_catch (tag=tag@entry=45936, func=func@entry=0x4ea3e0 , arg=arg@entry=0) at eval.c:1080 #13 0x00000000004ea3b9 in command_loop () at keyboard.c:1091 #14 0x00000000004ee8e7 in recursive_edit_1 () at keyboard.c:697 #15 0x00000000004eec28 in Frecursive_edit () at keyboard.c:768 #16 0x00000000004182bb in main (argc=3, argv=0x7fffe9ed0908) at emacs.c:1629 ``` This led me to the term.c file at 1895 (emacs 25.1.90), inside the turn_on_face function. Notice face_id=33 on frame 0 args. That was equal to f->face_cache->used which means FACE_FROM_ID returns NULL and causes the segfault in turn_on_face. I tried looking around to understand why this was happening but I did not uncover much. Then I tried finding a fix for the problem at hand, more exactly what to do when FACE_FROM_ID returns a NULL and how to deal with it so that it would no longer segfault. Here is what I came up with: * I could simply return; from turn_on_face (and the complementary turn_off_face) function on NULL. From what I understand this means leave text on the screen as is, don't redraw. This is inside the attached 001.patch * I could return the defualt face from FACE_FROM_ID. This would mean text would be displayed on screen with an unexpected default face, but at least it would not crash. The fix is inside the attached 002.patch (emacs 25) and 004.patch (emacs 26). * I could get the default face directly in the turn_on_face function in case of NULL, in case modifying the behaviour of FACE_FROM_ID is unwanted. This is inside the attached 003.patch. Now let me explain how exactly you can reproduce the bug: * First you will need a linux environment. This bug should be reproducible on any linux. You could do it on your own linux or you could get my current setup: VirtualBox and https://manjaro.org/get-manjaro/ xfce. * Then you will need emacs and xclip installed. You can install them from your package manager or from source, I've reproduced the bug with the following versions: 25.1.1, 25.1.90 and when building master from source. * Open a terminal and either make it fullscreen or maximized. * To install spacemacs you first need to remove ~/.emacs.d and ~/.emacs and then execute the following commands: git clone https://github.com/syl20bnr/spacemacs ~/.emacs.d curl -fSLo ~/.spacemacs https://raw.githubusercontent.com/sdwolf/dotfiles/master/.spacemacs * Now you must start emacs inside a relatively large git repository. I have chosen emacs's repo for this. cd emacs emacs -nw . * You now have to wait untill emacs gets all the packages. when this is done you will have exactly the same setup as I have on all my machines. * You have to stop emacs and start it again. You can either do C-x C-c or :qa! since it used evil-mode (vim style). * When you have it started again you should see 2 thigs. First on the left neotree opened with the contents of the current directlry, which should be the contents of the emacs repo. On the right would be dired with the same content. * From this place you need to press p f (that is spacebar followed by 'p' followed by 'f' on separate key strokes, do not hold down the keys, just press). This will bring up helm in the lower part of the screen. The idea is to open a relatively large file so that emacs has a lot of work to do and potentially trigger the segfault. The cursor will be on helm's search so you can type "src/term.c" (without the quotes) then press return (RET). If this does not crash emacs, you will have to move to a relatively large line number, ex 1800 and close emacs. This means that next time you open this file, emacs will open it at that line number. To move to that line number just type ":1800" and pres return (RET). To close emacs from here you can type ":qa!" and press return (RET). * You will have to open emacs again and do the above step again. This manages to trigger the segfault every time in my case. Note that it should take a relatively long time to open this file (6--10 seconds), so please wait patiently. Some things i've observed while digging with gdb: - Before opening helm in the setup above there are 28 faces in the face_cache. - After I open helm the cache fills with around 48 faces. - When i hit return after selecting a file, the cache fills up with more faces, until it gets to displaying the frame corresponding to the file (buffer). Then the face_cache drops to 33 (f->used == 33). - When it gets to the line where it must redisplay helm (vpos == 29 on dgb frame 2 above), it wants to redisplay the faces for helm but they are no longer in the cache, so FACE_FROM_ID returns NULL and a crash happens when the code dereferences the porinter a line below. - Since helm dissapears a few moments later, it's no problem if you just skip over this with a return or if you use a default face. - On emacs 25 with any of my patches applied, for a fraction of a second after pressing return and helm closing, you can still see the lower left corner of the screen (where the neotree area resides) still having the contents of helm. But that part is imediatly redrawn with the content of neotree. On emacs 26 that part does not get redrawn, untill you do an action like moving up/down one page or switch to neotree. This might be an inconvenience but in my opinion it's better than having a segfault. Hopefully I've managed to describe the problem (and potentially the patches I've attached are helpfull). Feel free to ask if you need further clarifications. Right now I am using my patched version of emacs to do my work and it would be great if a fix or workaround for this would be available in the default versions. For reference, here is an issue on github direclty related to this problem: https://github.com/syl20bnr/spacemacs/issues/8197 Thank you, Codrut