Neovide: [MacOS Catalina 10.15.3] segmentation fault in release mode
When I run the target/release/neovide binary, I get either
neovide(57928,0x10b64ddc0) malloc: Incorrect checksum for freed object 0x7fe99c264870: probably modified after being freed.
Corrupt value: 0x7fe99c264550
neovide(57928,0x10b64ddc0) malloc: *** set a breakpoint in malloc_error_break to debug
or just
[1] 58061 segmentation fault ./neovide
It works fine when I run the debug one (target/debug/neovide).
Same happens when I use cargo run and cargo run --release.
I believe the same issue was originally reported here https://github.com/Kethku/neovide/issues/73#issuecomment-584540091
Tested on the latest master (67468b2).
mdudzinski
All 60 comments
This is VERY strange... I'm sorta at a loss for how to investigate this
Kethku
on 12 Feb 2020
I can imagine. Unfortunately I don't know Rust and I haven't done any low-level programming for ages. So I tried to find the latest working commit which is > 971bb3d
Just a note that I had to do a 'surgery' on 'Cargo.lock' file to point it to the correct commit (otherwise it wouldn't compile)
[[package]]
name = "winit"
version = "0.20.0"
-source = "git+https://github.com/filnet/winit?branch=fix-panic-at-redraw-event-in-non-redraw-phase#1ddd984bdbec45e5345632e0999851c47f2b372d"
+source = "git+https://github.com/filnet/winit?branch=fix-panic-at-redraw-event-in-non-redraw-phase#277e3527fe21d975b7fa8adf7b26040a2201ed27"
After I reverted the next commit - 1853652 - keeping only the above wininit change from the Cargo.lock file (which is also present in the 'broken' commit > https://github.com/Kethku/neovide/commit/1853652085d39ef5f63096b875453ea1daa2a79e#diff-d2ede298d9a75c849170d6ef285eda1eR2103), the app launched in the release mode successfully.
Looks to me like one of the updated dependencies may be causing this issue.
mdudzinski
on 12 Feb 2020
Ok interesting. Then I think the fix is for me to hurry up and finish the move to sdl instead of winit which should be much more stable. In the meantime I will link to this issue in the upstream winit PR so they are aware that something broke. Thanks so much for doing the investigation! It helps me out a ton
Sent with GitHawk
Kethku
on 12 Feb 2020
@Kethku No worries! Trying do my best to help, I like that project and thanks for making it crossplatform, it's not an easy task.
Just to make sure we're on the same page - the winit init change in the lock file - from git+https://github.com/filnet/winit?branch=fix-panic-at-redraw-event-in-non-redraw-phase#1ddd984bdbec45e5345632e0999851c47f2b372d to git+https://github.com/filnet/winit?branch=fix-panic-at-redraw-event-in-non-redraw-phase#277e3527fe21d975b7fa8adf7b26040a2201ed27 - is the one that works and is required because the wininit commit 1ddd984bdbec45e5345632e0999851c47f2b372d is no longer present on the fix-panic-at-redraw-event-in-non-redraw-phase branch. One of other updated package(s) broke the release build on MacOS. Will try to narrow it down.
mdudzinski
on 13 Feb 2020
@Kethku No worries! Trying do my best to help, I like that project and thanks for making it crossplatform, it's not an easy task.
Just to make sure we're on the same page - the winit init change in the lock file - from
git+https://github.com/filnet/winit?branch=fix-panic-at-redraw-event-in-non-redraw-phase#1ddd984bdbec45e5345632e0999851c47f2b372dtogit+https://github.com/filnet/winit?branch=fix-panic-at-redraw-event-in-non-redraw-phase#277e3527fe21d975b7fa8adf7b26040a2201ed27- is the one that works and is required because the wininit commit 1ddd984bdbec45e5345632e0999851c47f2b372d is no longer present on thefix-panic-at-redraw-event-in-non-redraw-phasebranch. One of other updated package(s) broke the release build on MacOS. Will try to narrow it down.
@mdudzinski
Sorry I am getting a little confused. What commit version do you use? And then you just replace the one line in the lock file?
Thanks in advance!
HallerPatrick
on 13 Feb 2020
This commit https://github.com/Kethku/neovide/commit/1853652085d39ef5f63096b875453ea1daa2a79e breaks the release binary on MacOS.
That commit only bumps versions of number of dependencies.
You have to keep the following change from that commit though https://github.com/Kethku/neovide/commit/1853652085d39ef5f63096b875453ea1daa2a79e#diff-d2ede298d9a75c849170d6ef285eda1eR2103 because otherwise it will fail with the following error:
➜ neovide (master) ✗ cargo run --release
Updating git repository `https://github.com/filnet/winit`
error: failed to load source for a dependency on `winit`
Caused by:
Unable to update https://github.com/filnet/winit?branch=fix-panic-at-redraw-event-in-non-redraw-phase#1ddd984b
Caused by:
revspec '1ddd984bdbec45e5345632e0999851c47f2b372d' not found; class=Reference (4); code=NotFound (-3)
For a better visualisation, please take a look at my fork -> https://github.com/mdudzinski/neovide/tree/issue_126.
This commit reverts the broken commit but won't compile because of the above error:
https://github.com/mdudzinski/neovide/commit/77fafcbef5aab424513d19b97435284bd49bd1f0
This commit brings back the winit change in the Cargo.lock file so the app can compile
https://github.com/mdudzinski/neovide/commit/5ae2a7078ad2b26de8bb14a38e46545d16373f1b
So one of the other updated dependencies from https://github.com/Kethku/neovide/commit/1853652085d39ef5f63096b875453ea1daa2a79e has broken the MacOS release binary.
I hope that helps.
mdudzinski
on 14 Feb 2020
As mentioned above, I am working on a port to sdl which is looking promising. I'm hoping to merge it in the coming days
Kethku
on 16 Feb 2020
the port is ready to try in the sdl2 branch. I am testing it as my current driver now and haven't run into any issues. That said, I am running on windows only, so if anybody here could test it out, that would be great. I am planning on merging it to master in the next couple of days.
Kethku
on 16 Feb 2020
@Kethku Hey I tested the branch on my mac and run into runtime errors.
[mvk-error] VK_ERROR_INITIALIZATION_FAILED: vkCreateMacOSSurfaceMVK(): On-screen rendering requires a layer of type CAMetalLayer.
thread 'main' panicked at 'Failed to create renderer: VkError(ERROR_INITIALIZATION_FAILED)', src/window.rs:75:32
It probably has to do with using sdl. Did you test this on a linux machine?
HallerPatrick
on 16 Feb 2020
Ok interesting. Let me try something
Kethku
on 16 Feb 2020
Ok I updated surface creation @HallerPatrick could you pull and try again?
Kethku
on 16 Feb 2020
Neovide is now working in dev mode fine, even tho it has a pretty far zoom :P
HallerPatrick
on 17 Feb 2020
ok it builds though. In release mode does it still segfault?
Kethku
on 17 Feb 2020
zoom wise, neovide takes into account dpi settings and corrects for them. That code path is new though, so it may still have bugs especially on mac or linux
Kethku
on 17 Feb 2020
ok it builds though. In release mode does it still segfault?
Still segfault...
HallerPatrick
on 17 Feb 2020
Hrmmm rereading, @mdudzinski pointed out font-kit is the source of the issue. I'm doing some investigation now
Kethku
on 17 Feb 2020
Let me know, so I can test it.
HallerPatrick
on 17 Feb 2020
Probably won't happen today. @mdudzinski pointed out that something caused the problem in the update of font-kit. I will probably have to make an issue on the font-kit repo, but given that I don't have access to a mac readily available, I'm not sure I can provide sufficient details for such an issue to be useful at the moment.
Kethku
on 17 Feb 2020
Can you link where @mdudzinski mentions this, maybe we can try to figure something out. I'm now not realy familiar with your codebase, but would try to dig into it, to solve this.
HallerPatrick
on 17 Feb 2020
I'd love the help. @mdudzinski previously in this thread determined which commit caused the issue: https://github.com/Kethku/neovide/issues/126#issuecomment-586186915. The commit in question made 2 changes: it bumped the version of a library called font-kit we use to look up system font information and parse font files, and it updated the package lock file which bumped a series of other packages by a minor version or two.
So either font-kit 5.0 doesn't work on Mac, or one of the minor versions is causing the issue. My gut is the first one, but I can't really tell for sure.
My first step would be to take master, swap font-kit 5.0 to 4.0 in the Cargo.toml file and see if that fixes it. If not, I would start disabling half of the cargo.lock changes recursively to determine which of the minor package bumps is the issue.
Once we can figure out which of the packages is the source of the issue, we can either revert the update and/or make an upstream issue to see if the upstream package managers can help us out.
Sent with GitHawk
Kethku
on 17 Feb 2020
Okay I followed you instruction. I checked out master, changed font-kit to 0.4.0 and also had to change skribo to
skribo = { git = "https://github.com/linebender/skribo", rev = "03c63ac17bb93e29f82e959dac94027935a21159" }
to avoid skribo requiring font-kit 0.5.0.
And this fixes the problem. No weird behaviour on startup up and font size went also down to normal.
HallerPatrick
on 17 Feb 2020
Ok this is a bad sign because scribo includes a bug fix which depends on font-kit 0.4 and effects linux machines. But this may give me sufficient evidence to go make an issue on their page
Kethku
on 17 Feb 2020
I was getting this issue as well (macos 10.14.6). I tried building master of neovim, and master of neovide (with the suggested changes above) and am now getting this error (instead of the "incorrect checksum" error I was getting before):
[1] 44465 segmentation fault ./neovide
svermeulen
on 23 Feb 2020
I'm not sure what segmentation fault ./neovide means. If you build in debug mode does it give a more useful error? I'm hesitant to make an issue on the font-kit page until I can give them more info about what is actually going on. Unfortunately given that I don't have access to a mac really at all, I don't have the ability to debug this myself.
Kethku
on 23 Feb 2020
Ok I tried debug mode but the issue did not occur. I then re-built in release mode and confirmed again that the issue occurs there. I also grabbed some crash info this time in case that's helpful:
svermeulen
on 23 Feb 2020
And I get the same results on master of neovide and also after applying the suggested fixes here
svermeulen
on 23 Feb 2020
oh duh. My bad. Mixed up issues. This only happens on release mode. DUh.
Kethku
on 23 Feb 2020
Ok I made an upstream issue: https://github.com/servo/font-kit/issues/129
Maybe that will yield some idea as to whats going on.
Kethku
on 24 Feb 2020
If I want to reproduce this, how should I do that? Running cargo run from the master branch gives me:
thread 'tokio-runtime-worker' panicked at 'Could not locate or start the neovim process: No such file or directory (os error 2)', src/error_handling.rs:5:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'Failed to create window: SdlError("Failed to load Vulkan Portability library")', src/window.rs:84:22
This includes several error dialogs about the vulkan libraries being unsigned, which suggests the cause of the final panic. I followed https://github.com/Kethku/neovide#mac and used homebrew.
Edit: Nevermind, I found the note at the bottom of https://support.apple.com/en-ca/guide/mac-help/mh40616/mac and that allowed me to tell macOS to allow loading the unsigned libraries, and I saw a neovim window before it crashed. Progress!
I am now stuck on:
joshmatthews@joshmatthews-fcmd6r neovide % cargo run --release
Finished release [optimized + debuginfo] target(s) in 0.14s
Running `target/release/neovide`
thread 'tokio-runtime-worker' panicked at 'Could not locate or start the neovim process: No such file or directory (os error 2)', src/error_handling.rs:5:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'Could not send UI command from the window system to the neovim process.: channel closed', src/error_handling.rs:5:5
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
zsh: abort cargo run --release
Edit 2: fixed it by running brew install neovim.
jdm
on 24 Feb 2020
Unfortunately, I now have a working cargo run and cargo run --release and don't see any crashes when I type random strings. Are there any more specifics steps to reproduce that I can follow?
jdm
on 24 Feb 2020
@HallerPatrick can you give more details about your machine? Maybe there is an operating system version differential?
Sent with GitHawk
Kethku
on 24 Feb 2020
@mdudzinski maybe you have some repro hints as well?
Sent with GitHawk
Kethku
on 24 Feb 2020
Is it possible you guys have guifonts configured in your vim config?
Kethku
on 24 Feb 2020
@jdm could you try setting the guifont to some system font by opening neovide, and typing :set guifont=<font name here with backslash escaped spaces>:h12? Font-kit isn't hit strongly unless the guifont is set
Kethku
on 25 Feb 2020
I tried with :set guifont=Times\ New\ Roman:h12 and the font changed but I was still able to type things without any issues.
jdm
on 25 Feb 2020
Hrmm. Welp I'm not sure what to try next... I appreciate the effort to repro though. I think at this point waiting till the above folks can chime in is best
Sent with GitHawk
Kethku
on 25 Feb 2020
@Kethku Yep I do have a guifont configured but when I remove it from the config, I still get the segfault crash in release.
mdudzinski
on 25 Feb 2020
Very weird. Can you give more details about your os version?
Kethku
on 25 Feb 2020
I'm running 10.15.3.
mdudzinski
on 25 Feb 2020
Ah yes youre the issue op. My bad
Kethku
on 25 Feb 2020
At this point I think its out of my hands. Seems like its not effecting everyone on MacOs, so until we can figure out the root of the issue, I'm not sure we can move forward on figuring out a fix. Luckily the performance even in debug mode isn't terrible, so until then using debug builds can work... @jdm Thanks so much for the attempt at reproing.
Kethku
on 25 Feb 2020
Im also running MacOS Catalina Version 10.15.3.
HallerPatrick
on 25 Feb 2020
I get this issue on macOS Mojave 10.14.6
svermeulen
on 25 Feb 2020
I ran git bisect with the following result:
1853652085d39ef5f63096b875453ea1daa2a79e is the first bad commit
commit 1853652085d39ef5f63096b875453ea1daa2a79e
Author: Keith Simmons <[email protected]>
Date: Wed Feb 5 14:59:14 2020 -0800
update fontkit and lock file
:100644 100644 dec12d939e71e180b0895a16b9bc43237f3f0ee0 abebfb5dfcfa4aba4e56b950406da37eb83d5f40 M Cargo.lock
:100644 100644 b03703dcba4256fa83e0e3604b0a33dc39791eb7 9b8fe8cb7da12edb8f95cbdfc24124bbc150afc7 M Cargo.toml
It would be likely be most useful for someone who can reproduce to add a Cargo override for font-kit, make a local clone, and bisect the commits between the new and old versions.
jdm
on 25 Feb 2020
I reverted font-kit in a fork of skribo. Could someone here encountering this issue try building from possible-macos-fix and running release to see if it fixes the issue?
Kethku
on 2 Mar 2020
@Kethku I tried running cargo run --release in a clean version of the possible-macos-fix branch just now and got the same result ('segmentation fault')
svermeulen
on 3 Mar 2020
can you confirm the source of skribo?
Sent with GitHawk
Kethku
on 3 Mar 2020
Or even better, which version of fontkit was used to build
Sent with GitHawk
Kethku
on 3 Mar 2020
Here is the output from cargo run --release which indicates font-kit v0.4.0 (though I do not know rust so correct me if this isn't helpful)
Compiling libc v0.2.67
Compiling cfg-if v0.1.10
Compiling cc v1.0.50
Compiling autocfg v1.0.0
Compiling lazy_static v1.4.0
Compiling proc-macro2 v1.0.9
Compiling unicode-xid v0.2.0
Compiling memchr v2.3.3
Compiling syn v1.0.16
Compiling log v0.4.8
Compiling bitflags v1.2.1
Compiling pkg-config v0.3.17
Compiling byteorder v1.3.4
Compiling adler32 v1.0.4
Compiling crc32fast v1.2.0
Compiling regex-syntax v0.6.14
Compiling core-foundation-sys v0.6.2
Compiling serde v1.0.104
Compiling semver-parser v0.7.0
Compiling glob v0.3.0
Compiling version_check v0.1.5
Compiling foreign-types-shared v0.1.1
Compiling encoding_rs v0.8.22
Compiling scopeguard v1.1.0
Compiling maybe-uninit v2.0.0
Compiling ryu v1.0.2
Compiling quick-error v1.2.3
Compiling unicode-width v0.1.7
Compiling slab v0.4.2
Compiling proc-macro2 v0.4.30
Compiling vec_map v0.8.1
Compiling ansi_term v0.11.0
Compiling termcolor v1.1.0
Compiling getrandom v0.1.14
Compiling curl v0.4.25
Compiling bindgen v0.52.0
Compiling strsim v0.8.0
Compiling arrayvec v0.4.12
Compiling rustc-hash v1.1.0
Compiling itoa v0.4.5
Compiling lazycell v1.2.1
Compiling proc-macro-nested v0.1.3
Compiling shlex v0.1.1
Compiling unicode-segmentation v1.6.0
Compiling same-file v1.0.6
Compiling peeking_take_while v0.1.2
Compiling unicode-xid v0.1.0
Compiling futures-core v0.3.4
Compiling futures v0.1.29
Compiling syn v0.15.44
Compiling nodrop v0.1.14
Compiling futures-sink v0.3.4
Compiling rayon-core v1.7.0
Compiling futures-task v0.3.4
Compiling futures-io v0.3.4
Compiling num-derive v0.2.5
Compiling pin-utils v0.1.0-alpha.4
Compiling autocfg v0.1.7
Compiling smallvec v1.2.0
Compiling arc-swap v0.4.4
Compiling block v0.1.6
Compiling sdl2 v0.33.0 (https://github.com/Rust-SDL2/rust-sdl2#4e81db58)
Compiling lzw v0.10.0
Compiling either v1.5.3
Compiling bytes v0.5.4
Compiling float-ord v0.2.0
Compiling color_quant v1.0.1
Compiling anyhow v1.0.26
Compiling fnv v1.0.6
Compiling pin-project-lite v0.1.4
Compiling scoped_threadpool v0.1.9
Compiling thread_local v1.0.1
Compiling miniz_oxide v0.3.6
Compiling inflate v0.4.5
Compiling cmake v0.1.42
Compiling semver v0.9.0
Compiling foreign-types v0.3.2
Compiling lock_api v0.3.3
Compiling humantime v1.3.0
Compiling textwrap v0.11.0
Compiling num-traits v0.2.11
Compiling crossbeam-utils v0.7.2
Compiling crossbeam-epoch v0.8.2
Compiling num-integer v0.1.42
Compiling num-rational v0.2.3
Compiling num-iter v0.1.40
Compiling nom v4.2.3
Compiling walkdir v2.3.1
Compiling futures-channel v0.3.4
Compiling heck v0.3.1
Compiling clang-sys v0.28.1
Compiling unicode-normalization v0.1.12
Compiling gif v0.10.3
Compiling rustc_version v0.2.3
Compiling hashbrown v0.6.3
Compiling rust-embed-utils v5.0.0
Compiling aho-corasick v0.7.8
Compiling quote v1.0.2
Compiling filetime v0.2.8
Compiling xattr v0.2.2
Compiling flate2 v1.0.13
Compiling core-foundation v0.6.4
Compiling iovec v0.1.4
Compiling atty v0.2.14
Compiling which v3.1.0
Compiling num_cpus v1.12.0
Compiling socket2 v0.3.11
Compiling malloc_buf v0.0.6
Compiling net2 v0.2.33
Compiling time v0.1.42
Compiling memmap v0.7.0
Compiling shared_library v0.1.9
Compiling signal-hook-registry v1.2.0
Compiling dirs v1.0.5
Compiling raw-window-handle v0.3.3
Compiling parking_lot_core v0.7.0
Compiling deflate v0.7.20
Compiling quote v0.6.13
Compiling tar v0.4.26
Compiling memoffset v0.5.3
Compiling bytes v0.4.12
Compiling clap v2.33.0
Compiling core-graphics v0.17.3
Compiling regex v1.3.4
Compiling libz-sys v1.0.25
Compiling curl-sys v0.4.26
Compiling libloading v0.5.2
Compiling objc_exception v0.1.2
Compiling harfbuzz-sys v0.3.4
Compiling mio v0.6.21
Compiling ash v0.29.0
Compiling parking_lot v0.10.0
Compiling crossbeam-queue v0.2.1
Compiling png v0.15.3
Compiling euclid v0.20.7
Compiling rmp v0.8.9
Compiling cexpr v0.3.6
Compiling tokio-io v0.1.13
Compiling core-text v13.3.2
Compiling unidiff v0.3.2
Compiling env_logger v0.7.1
Compiling toml v0.5.6
Compiling serde_json v1.0.48
Compiling mio-uds v0.6.7
Compiling chrono v0.4.10
Compiling rmpv v0.4.4
Compiling lyon_geom v0.14.1
Compiling winres v0.1.11
Compiling flexi_logger v0.14.8
Compiling lyon_path v0.14.0
Compiling objc v0.2.7
Compiling font-kit v0.4.0
Compiling crossbeam-deque v0.7.3
Compiling cocoa v0.19.1
Compiling neovide v0.4.0 (/Users/svermeulen/Projects/svkj/active/thirdparty/neovide)
Compiling rayon v1.3.0
Compiling metal v0.17.1
Compiling jpeg-decoder v0.1.18
Compiling sdl2-sys v0.33.0 (https://github.com/Rust-SDL2/rust-sdl2#4e81db58)
Compiling proc-macro-hack v0.5.11
Compiling tokio-macros v0.2.4
Compiling pin-project-internal v0.4.8
Compiling rust-embed-impl v5.5.0
Compiling async-trait v0.1.24
Compiling derive-new v0.5.8
Compiling tiff v0.3.1
Compiling const-random-macro v0.1.8
Compiling futures-macro v0.3.4
Compiling skia-bindings v0.26.1
Compiling image v0.22.5
Compiling harfbuzz v0.3.1
Compiling const-random v0.1.8
Compiling tokio v0.2.11
Compiling rust-embed v5.5.0
Compiling skribo v0.0.1 (https://github.com/kethku/skribo#86dbaaa1)
Compiling ahash v0.2.18
Compiling futures-util v0.3.4
Compiling lru v0.4.3
Compiling futures-executor v0.3.4
Compiling futures v0.3.4
Compiling skia-safe v0.26.1
Compiling pin-project v0.4.8
Compiling nvim-rs v0.1.1-alpha.0 (https://github.com/kethku/nvim-rs#3abe58a5)
Compiling skulpin v0.5.2 (https://github.com/Kethku/skulpin?branch=sdl2#9c62459e)
Finished release [optimized + debuginfo] target(s) in 3m 48s
Running `target/release/neovide`
ARG. I'm at a loss again
Kethku
on 3 Mar 2020
I can't fix this issue myself as I don't have a mac. Sorry folks
Kethku
on 7 Mar 2020
I had some time today, and really like this project, so attempted to dig deeper into this. But I don't know rust so could only get so far.
I create this branch in my fork of neovide, which branches off commit 971bb3d (which is the last commit of neovide that runs on my mac). All it contains is a change to Cargo.toml to force it to use a verison of skribo that uses font-kit version 0.4.0:
skribo = { git = "https://github.com/linebender/skribo", rev = "a9e323b7e27f4f04eecc88f1915ce0364f512404" }
If I run cargo run --release in this branch it works fine. However, if I run cargo update and then execute cargo run --release, it fails. So my guess is that one of these dependency changes causes the issue?
➜ neovide git:(MacOsIssue) cargo update
Updating crates.io index
Updating git repository `https://github.com/kethku/nvim-rs`
Updating git repository `https://github.com/linebender/skribo`
Updating git repository `https://github.com/kethku/skulpin`
Updating git repository `https://github.com/filnet/winit`
Updating aho-corasick v0.7.8 -> v0.7.9
Updating byteorder v1.3.2 -> v1.3.4
Updating chrono v0.4.10 -> v0.4.11
Updating crossbeam-channel v0.4.0 -> v0.4.2
Updating crossbeam-deque v0.7.2 -> v0.7.3
Updating crossbeam-epoch v0.8.0 -> v0.8.2
Updating crossbeam-utils v0.7.0 -> v0.7.2
Updating curl v0.4.25 -> v0.4.26
Updating curl-sys v0.4.25 -> v0.4.28+curl-7.69.0
Updating flexi_logger v0.14.6 -> v0.14.8
Updating futures v0.3.2 -> v0.3.4
Updating futures-channel v0.3.2 -> v0.3.4
Updating futures-core v0.3.2 -> v0.3.4
Updating futures-executor v0.3.2 -> v0.3.4
Updating futures-io v0.3.2 -> v0.3.4
Updating futures-macro v0.3.2 -> v0.3.4
Updating futures-sink v0.3.2 -> v0.3.4
Updating futures-task v0.3.2 -> v0.3.4
Updating futures-util v0.3.2 -> v0.3.4
Updating hermit-abi v0.1.6 -> v0.1.8
Updating image v0.22.4 -> v0.22.5
Updating libc v0.2.66 -> v0.2.67
Updating memchr v2.3.0 -> v2.3.3
Updating proc-macro2 v1.0.8 -> v1.0.9
Updating quote v1.0.2 -> v1.0.3
Updating regex-syntax v0.6.14 -> v0.6.16
Updating rust-embed v5.2.0 -> v5.5.0
Updating rust-embed-impl v5.2.0 -> v5.5.0
Updating rustc-hash v1.0.1 -> v1.1.0
Updating schannel v0.1.16 -> v0.1.17
Updating scopeguard v1.0.0 -> v1.1.0
Updating serde_json v1.0.46 -> v1.0.48
Updating skia-bindings v0.23.2 -> v0.26.1
Updating skia-safe v0.23.2 -> v0.26.1
Updating smithay-client-toolkit v0.6.4 -> v0.6.6
Updating syn v1.0.14 -> v1.0.16
Updating tokio v0.2.11 -> v0.2.13
Updating tokio-io v0.1.12 -> v0.1.13
Updating tokio-macros v0.2.4 -> v0.2.5
Updating which v3.1.0 -> v3.1.1
Updating winit v0.20.0 (https://github.com/filnet/winit?branch=fix-panic-at-redraw-event-in-non-redraw-phase#1ddd984b) -> #277e3527
➜ neovide git:(MacOsIssue) ✗
This definitely helps narrow it down. The thing I'm struggling with is that your crash log you posted earlier seems to indicate that the thread which crashed was thread 0 which was running the deconstructor on the harfbuzz blob.
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 neovide 0x000000010bdc6fdf hb_blob_destroy + 15 (hb-object.hh:276)
1 neovide 0x000000010bdc98e7 hb_ot_face_t::fini() + 151 (hb-ot-face-table-list.hh:54)
2 neovide 0x000000010bdc976b hb_face_destroy + 171 (hb-face.cc:273)
3 neovide 0x000000010bd0a347 neovide::renderer::caching_shaper::CachingShaper::font_base_dimensions::hd390aaeee1d17e15 + 3223 (mod.rs:182)
4 neovide 0x000000010bcafb30 neovide::renderer::Renderer::new::h48357aa667bbd9af + 128 (mod.rs:34)
5 neovide 0x000000010bcf5a31 neovide::window::ui_loop::he14e601c7a5d36c7 + 209 (window.rs:64)
6 neovide 0x000000010bcb1586 std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h5dbfeb1546a6dd7f + 6 (rt.rs:67)
7 neovide 0x000000010c33a748 std::panicking::try::do_call::h77eb563f55a56484 + 24 (panicking.rs:292)
8 neovide 0x000000010c341c6f __rust_maybe_catch_panic + 31 (lib.rs:86)
9 neovide 0x000000010c33b05e std::rt::lang_start_internal::h3d261fac4b6382f2 + 542 (rt.rs:51)
10 neovide 0x000000010bd0aaa9 main + 41
11 libdyld.dylib 0x00007fff5a4703d5 start + 1
That seems to indicate that something about the way we are interacting with the harfbuzz library is messed up. This leads back to skribo being the possible culprit, but it seems like that hasn't been changed in your update? I'm not sure.
Kethku
on 8 Mar 2020
Narrowed it down a bit further:
git co 971bb3dcargo run --release(works fine)cargo update -p skia-safe. Output:
Updating crates.io index Updating skia-bindings v0.23.2 -> v0.26.1 Updating skia-safe v0.23.2 -> v0.26.1cargo run --release(seg fault)
svermeulen
on 8 Mar 2020
I build my skulpin branch with the skia-safe bindings locked to 0.23.2. I just pushed the change to master because none of the skia-safe changes seemed blocking. Can you try now on master? If this works, then I will create an issue in the skia-safe repo to see if we can get some help from them to get it fixed upstream.
Kethku
on 8 Mar 2020
Yep master runs now :D
svermeulen
on 8 Mar 2020
Awesome! I will close this and make an issue in the upstream repo
Kethku
on 8 Mar 2020
Kethku
on 8 Mar 2020
Super excited to run this on OSX and don't have time to install the dependencies and build it myself. The current release 0.5.0 exhibits this issue. Would be very greatful if somebody has time to cut a new release.
oliverdain
on 17 Mar 2020
Related issues
szbergeron
·
28Comments
habamax
·
67Comments
valrus
·
21Comments
SirVer
·
26Comments
ABitMoreDepth
·
25Comments
Most helpful comment
Narrowed it down a bit further:
git co 971bb3dcargo run --release(works fine)cargo update -p skia-safe. Output:Updating crates.io index Updating skia-bindings v0.23.2 -> v0.26.1 Updating skia-safe v0.23.2 -> v0.26.1cargo run --release(seg fault)