neovide: Seg Fault collection.rs:130:32
Hi! I’m currently running arch 5.11.12-arch1-1 My cpu is an AMD Ryzen 3 3100 My gpu an sapphire rx580 Rust version 1.51.0 Compiled the latest (54b967f) version
When I run neovide I get:
Ignored client type property: "attributes"
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /home/lerusse/.cache/paru/clone/neovide-git/src/neovide-git/CARGO/git/checkouts/skribo-3c422fce25a33836/a35c876/src/collection.rs:130:32
stack backtrace:
0: 0x56102c434050 - <unknown>
1: 0x56102c3584ec - <unknown>
2: 0x56102c4338c1 - <unknown>
3: 0x56102c433225 - <unknown>
4: 0x56102c43290a - <unknown>
5: 0x56102c451e08 - <unknown>
6: 0x56102c451d7c - <unknown>
7: 0x56102c451d2d - <unknown>
8: 0x56102c356840 - <unknown>
9: 0x56102c3566d1 - <unknown>
10: 0x56102c41d5ae - <unknown>
11: 0x56102c28beb9 - <unknown>
12: 0x56102c2a6f9c - <unknown>
13: 0x56102c485e30 - <unknown>
14: 0x56102c3303a6 - <unknown>
15: 0x56102c2d3e13 - <unknown>
16: 0x56102c32ca75 - <unknown>
17: 0x7f0f07289b25 - __libc_start_main
18: 0x56102c28877e - <unknown>
19: 0x0 - <unknown>
[1] 149608 segmentation fault (core dumped)
I’ve tried installing amdvlk as per issue 209 and installing vulkan-radeon with no better result.
Thanks 😃
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 4
- Comments: 19 (9 by maintainers)
This is a font collection issue. If you install Noto Sans Mono font does the issue change? Skribo is a wrapper around harfbuzz which is our shaper. The current main branch uses a combination of skia and font-kit fonts to achieve more consistent spacing of characters and such. The opengl branch has changed this to use a different set of dependencies that I find work somewhat better, however that branch has other issues on some configurations of linux which I want to hammer out before merging.
Its possible the opengl branch will cause more issues, but could some of you encountering this try it to see if the font problem goes away?
Neovide has a few threads. One for handling neovim input/output, one for processing editor state changes, and one for handling window events and rendering to the screen. Since the guifont is configured in the vim config, and might not be configured at all, its possible that we use the default fonts which are (currently) hard coded for initial renders. Then when neovim boots up and reports settings to the other threads, it updates.
This means its possible that we try to load the default font and fail before we get the actual font to use. Its likely not a complicated fix, but would require fiddling around with the load order or replacing the hard coded default fonts per platform with some call to a skia library to find the os default font.
@deaniiyu when I’ve encountered that in the past, its been a problem with the font name set in guifont rather than a refusal to load any other font.