Crash when trying to open a file

[AlphaKeks]

When trying to open a basic markdown file I'm getting the following error:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /build/inlyne-0.3.1-vendor.tar.gz/wgpu-hal/src/gles/egl.rs:751:73

Full stacktrace:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /build/inlyne-0.3.1-vendor.tar.gz/wgpu-hal/src/gles/egl.rs:751:73
stack backtrace:
   0:     0x555d4922a8b0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf014552b94f53b0b
   1:     0x555d49255c9f - core::fmt::write::hd931ce1f65786f99
   2:     0x555d49222e87 - std::io::Write::write_fmt::h6a6fd63a04e82ec7
   3:     0x555d4922a6b5 - std::sys_common::backtrace::print::h1e42468794e7b82c
   4:     0x555d4920f111 - std::panicking::default_hook::{{closure}}::hbe45423b43205803
   5:     0x555d4920edaf - std::panicking::default_hook::h84640917dec96f40
   6:     0x555d4920f5b9 - std::panicking::rust_panic_with_hook::h3f828bf7de94854a
   7:     0x555d4922ab51 - std::panicking::begin_panic_handler::{{closure}}::h1494d1b7b833ecd5
   8:     0x555d4922a986 - std::sys_common::backtrace::__rust_end_short_backtrace::hfb56cb4321fb1fc8
   9:     0x555d4920f2e2 - rust_begin_unwind
  10:     0x555d484a2cb3 - core::panicking::panic_fmt::h69ad0a157a771ebb
  11:     0x555d484a2d43 - core::panicking::panic::h49ef28648bcd6145
  12:     0x555d4912d8dd - <wgpu_hal::gles::egl::Instance as wgpu_hal::Instance<wgpu_hal::gles::Api>>::init::ha76d23d357289a11
  13:     0x555d490b2836 - wgpu_core::instance::Instance::new::hef8a7e54de18c5e1
  14:     0x555d4905abc8 - <wgpu::backend::direct::Context as wgpu::context::Context>::init::h886b1226b98ec796
  15:     0x555d48f8f076 - wgpu::Instance::new::h21dab5fc8d49be2f
  16:     0x555d48530c2a - pollster::block_on::hcb855b888d4890ea
  17:     0x555d4859b311 - inlyne::main::hb782d86bb8f8afd6
  18:     0x555d484c8633 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5541b693798d8478
  19:     0x555d484c8a1d - std::rt::lang_start::{{closure}}::h1ab27ab68fbbc8d4
  20:     0x555d49203c27 - std::rt::lang_start_internal::hbcbc84fca12d560d
  21:     0x555d4859cd45 - main
  22:     0x7fcb0a55dace - __libc_start_call_main
  23:     0x7fcb0a55db89 - __libc_start_main@@GLIBC_2.34
  24:     0x555d484a3345 - _start

I'm using NixOS unstable and installed inlyne using nix-shell. Could I be missing dependencies that aren't included in the nix build?

[CosmicHorrorDev]

It looks like this may be an issue upstream. It would be helpful to see if you can reproduce the same issue when running some of the examples from the wgpu repo e.g.

# From the root of the `wgpu` repo
$ cargo run --example cube

You should see a cube with the mandlebrot set on it

I sifted through the issues in the wgpu repo and didn't notice anyone listing the same panic message that you did, but the issues there are normally heavily system specific

[AlphaKeks]

The command you suggested didn't work. The only two examples that are available are halmark and raw-gles. I'm not sure why though. If I cd examples I can see all the other ones, so going into the cube example and just running cargo run I get the following error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: XKBNotFound', /home/alphakeks/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.3/src/platform_impl/linux/x11/mod.rs:302:85
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: core::result::Result<T,E>::unwrap
             at /build/rustc-1.72.1-src/library/core/src/result.rs:1076:23
   4: winit::platform_impl::platform::x11::EventLoop<T>::new
             at /home/alphakeks/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.3/src/platform_impl/linux/x11/mod.rs:302:13
   5: winit::platform_impl::platform::EventLoop<T>::new_x11_any_thread
             at /home/alphakeks/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.3/src/platform_impl/linux/mod.rs:803:25
   6: winit::platform_impl::platform::EventLoop<T>::new
             at /home/alphakeks/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.3/src/platform_impl/linux/mod.rs:787:30
   7: winit::event_loop::EventLoopBuilder<T>::build
             at /home/alphakeks/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.3/src/event_loop.rs:128:25
   8: winit::event_loop::EventLoop<()>::new
             at /home/alphakeks/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.3/src/event_loop.rs:201:9
   9: wgpu_example::framework::setup::{{closure}}
             at /home/alphakeks/tmp/wgpu/examples/common/src/framework.rs:99:22
  10: pollster::block_on
             at /home/alphakeks/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pollster-0.3.0/src/lib.rs:128:15
  11: wgpu_example::framework::run
             at /home/alphakeks/tmp/wgpu/examples/common/src/framework.rs:405:17
  12: cube::main
             at ./src/main.rs:376:5
  13: core::ops::function::FnOnce::call_once
             at /build/rustc-1.72.1-src/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I used nix develop nixpkgs#inlyne which should give me a dev-shell with the same dependencies that are included in the inlyne nix package, since wgpu doesn't provide a flake or dev-shell.

Running any of the other examples fails with the same error.

The error is talking about xkb which seems weird to me considering that I'm running X11. I am using a custom xkb layout though, so I thought that might be the issue. setxkbmap us followed by running the example again yielded the same error.

I very much assume both are caused by missing system dependencies, but I have no idea which. I will try to dig in more and report back if I can figure it out, but if anyone else using Nix sees this issue I would appreciate some hints.

[CosmicHorrorDev]

The command you suggested didn't work. The only two examples that are available are halmark and raw-gles. I'm not sure why though.

Ah it looks like they've changed the structure since I last pulled. I also only see halmark and raw-gles for the examples now

---

That error message looks quite different than the first, but that's not really surprising since it's using newer versions of dependencies. It looks like the winit error is coming down to this function returning None

https://docs.rs/xkbcommon-dl/0.4.1/src/xkbcommon_dl/lib.rs.html#303-314

pub fn xkbcommon_option() -> Option<&'static XkbCommon> {
    static XKBCOMMON_OPTION: OnceCell<Option<XkbCommon>> = OnceCell::new();
    XKBCOMMON_OPTION
        .get_or_init(|| {
            open_with_sonames(
                &["libxkbcommon.so.0", "libxkbcommon.so"],
                None,
                |name| unsafe { XkbCommon::open(name) },
            )
        })
        .as_ref()
}

[AlphaKeks]

I tried including libxkbcommon in my dev-shell as well but I keep getting the same error.

[CosmicHorrorDev]

It looks like open_with_sonames() logs on failures, and the wgpu examples are all setup with env_logger. You should be able to see log messages from the failure by passing the env var RUST_LOG="xkbcommon_dl=info" when running the wgpu example

[AlphaKeks]

Not very helpful either unfortunately.

[2023-11-01T22:57:04Z INFO  xkbcommon_dl] Failed loading `libxkbcommon.so.0`. Error: CantOpen(DlOpen { desc: "libxkbcommon.so.0: cannot open shared object file: No such file or directory" })
[2023-11-01T22:57:04Z INFO  xkbcommon_dl] Failed loading `libxkbcommon.so`. Error: CantOpen(DlOpen { desc: "libxkbcommon.so: cannot open shared object file: No such file or directory" })
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: XKBNotFound', /home/alphakeks/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.3/src/platform_impl/linux/x11/mod.rs:302:85

I tried both with and without libxkbcommon, but nothing changes. I also tried compiling inlyne myself and running it and I get a different error!

Error: Failed to find an appropriate adapter

The error comes from here.

It's still a WGPU error so that might be related?

[CosmicHorrorDev]

Hmmm, very interesting 🤔

Currently inlyne is still using older versions of wgpu and winit. I'll work on updating things and we'll see what kind of error happens then. It'll likely be at least a week before I have time to work on that though

[AlphaKeks]

Update!

I figured out how to get past the Failed to find an appropriate adapter error. The solution is to add the following to the nix build:

preFixup = lib.optionalString stdenv.isLinux ''
    patchelf \
        --add-needed "${pkgs.libGL}/lib/libEGL.so.1" \
        --add-needed "${pkgs.vulkan-loader}/lib/libvulkan.so.1" \
        $out/bin/inlyne
'';

This resolved that issue, but lead to another:

thread 'main' panicked at /home/alphakeks/.cargo/git/checkouts/cosmic-text-dc629381e389cc34/e1e9fb5/src/shape.rs:130:33:
no default font found

Searching through cosmic-text issues though I found this, so adding fontdb = { version = "0.13.1", features = ["fontconfig"] } to the Cargo.toml and compiling again with that finally made inlyne open!

From what I can tell those two things should fix the issue. If you want I can open a PR for it, but since you said you wanted to update dependencies anyway, I can leave it to you as well if you would prefer that.

[CosmicHorrorDev]

Not sure how we would go about solving the first bit. Is it an issue with the nix package definition, or from breakages since the last release, or system specific?

As for toggling on the feature flag, you're more than welcome to open a PR! Make sure to add a comment indicating as to why it's needed

[AlphaKeks]

I believe it's an issue with the nix package definition. I have had one friend who also uses NixOS test the inlyne package and it also wouldn't open for them. Since inlyne depends on WGPU and therefore Vulkan (for AMD GPUs at least), I believe the patch should be part of the inlyne nix package.

I use NixOS unstable so I'm not sure how this behaves on NixOS stable, but I wouldn't expect it to work there either. The current package already has some pacthelf calls so I don't think there is any downside to adding 2 more?

I will open a PR for the dependency, thank you very much!

[AlphaKeks]

I assume you will update the nix package definition if you mark this as closed?

[CosmicHorrorDev]

This got closed with the merge of #169 which seems fine since that covers all we can do in this repo. Feel free to open an issue downstream in nix packages to cover the patchelf bits since that's where the package definition lives (and you're far better equipped to handle following up with hose changes than me)

[AlphaKeks]

Oh, alright! I assumed you were the one maintaining it, but I will open a PR for it then, thank you very much.

[CosmicHorrorDev]

Ahhhh, no I'm just a humble inlyne maintainer. I've been meaning to switch to NixOS, but I'm still using Arch at the moment

The definition was created by @figsoda who looks to still be the maintainer

[figsoda]

The definition was created by @figsoda who looks to still be the maintainer

Thanks for the ping, I am indeed the maintainer of the nix package. Would you be open to publish a new release for this?

[CosmicHorrorDev]

Sure! I can backport the change and cut a release for it over the next few days

I'll ping again after all that's been sorted :)

[CosmicHorrorDev]

@figsoda Got a little delayed, but just pushed out a release for v0.3.2 🎉