Crash "capacity overflow" when pressing keyboard "fn" key

matusbielik commented 3 months ago

Check for existing issues

[X] Completed

Describe the bug / provide steps to reproduce it

When pressing fn key on keyboard (e.g. to use F11 instead of decreasing volume), Zed crashes with following error:

➜  ~ zed --foreground
[2024-07-13T23:45:24+02:00 ERROR zed::reliability] {
  "thread": "main",
  "payload": "capacity overflow",
  "location_data": {
    "file": "library/alloc/src/raw_vec.rs",
    "line": 25
  },
  "backtrace": [
    "core::panicking::panic_fmt",
    "alloc::raw_vec::capacity_overflow",
    "alloc::raw_vec::handle_error",
    "gpui::platform::linux::platform::<impl gpui::platform::keystroke::Keystroke>::from_xkb",
    "<gpui::platform::linux::wayland::client::WaylandClientStatePtr as wayland_client::event_queue::Dispatch<wayland_client::protocol::wl_keyboard::WlKeyboard,()>>::event",
    "wayland_client::event_queue::queue_callback",
    "<core::cell::RefCell<calloop::sources::DispatcherInner<S,F>> as calloop::sources::EventDispatcher<Data>>::process_events",
    "<gpui::platform::linux::wayland::client::WaylandClient as gpui::platform::linux::platform::LinuxClient>::run",
    "gpui::platform::linux::platform::<impl gpui::platform::Platform for P>::run",
    "gpui::app::App::run",
    "zed::main",
    "std::sys_common::backtrace::__rust_begin_short_backtrace",
    "std::rt::lang_start::{{closure}}",
    "std::rt::lang_start_internal",
    "main",
    "__libc_start_main",
    "_start"
  ],
  "app_version": "0.143.6",
  "release_channel": "Zed",
  "os_name": "Linux Wayland",
  "os_version": "debian unknown",
  "architecture": "x86_64",
  "panicked_on": 1720907124842,
  "installation_id": "ce66244f-9985-4174-aec1-730a30f3a3ba",
  "session_id": "d17c4782-00e9-428f-bc53-d517565bd543"
}

It is reproducible for me - it happens every time. The external usb keyboard model when it happens is Keychron K1. With laptop keyboard it works fine. No other program has problems with this fn key.

Environment

Zed: v0.143.6 (Zed) OS: Linux Wayland Debian 12 Memory: 58.6 GiB Architecture: x86_64

If applicable, attach your `~/Library/Logs/Zed/Zed.log` file to this issue.

Zed.log

notpeter commented 3 months ago

@mrnugget I saw elsewhere you might have a Keychron Q3, if so can you see if you can reproduce this issue where Fn crashes zed?

mrnugget commented 3 months ago

Just tried it on Wayland. I cannot reproduce it. Neither in Win nor in Mac mode of the keyboard. I'll take a look at the code, maybe there's something obvious to fix there.

apricotbucket28 commented 3 months ago

I can also reproduce this with the prebuilt binaries when pressing the ordinal indicator key. Compiling from source does not have this issue.

Removing the bundled libxkbcommon.so.0 in .local/zed-nightly.app/lib fixes the crash.

ConradIrwin commented 3 months ago

@apricotbucket28 what version of libxkccommon do you have installed on your system? The build machines are Ubuntu 20 so we can get an old enough glibc, which ships with libxkbcommon-dev/focal,now 0.10.0-1

I have a workaround that should stop the panic, but it's still unlikely to work for those keys; likely due to a version mismatch. I wonder if we should upgrade the libxkbcommon on the build machines (or maybe assume that that's a dependency people will already have, but I'm nervous about that particularly for the headless installation).

Ideally we'd fallback to our bundled libraries only if the system one is absent. We currently do the fallback using rpath=$ORIGIN/../lib. As far as I'm aware there are two versions of rpath, neither of which quite works:

The "new" one which falls back to rpath if the system library cannot be found when a library is loaded directly from an application.
The "old" one which uses rpath in preference to the system libraries and works when a library loads another library transitively. (this is what we use currently) The ideal behavior is "Use the system libraries by preference, but fallback if necessary for dependencies loaded either form the app or our other shared libraries".

apricotbucket28 commented 3 months ago

@apricotbucket28 what version of libxkccommon do you have installed on your system? The build machines are Ubuntu 20 so we can get an old enough glibc, which ships with libxkbcommon-dev/focal,now 0.10.0-1

Running dnf5 info libxkbcommon:

dnf5 info libxkbcommon      
Updating and loading repositories:
Repositories loaded.
Installed packages
Name            : libxkbcommon
Epoch           : 0
Version         : 1.6.0
Release         : 2.fc40
Architecture    : x86_64
Installed size  : 328.3 KiB
Source          : libxkbcommon-1.6.0-2.fc40.src.rpm
From repository : <unknown>
Summary         : X.Org X11 XKB parsing library
URL             : http://www.x.org
License         : MIT AND X11 AND MIT-CMU
Description     : libxkbcommon is the X.Org library for compiling XKB maps into formats usable by
                : the X Server or other display servers.
Vendor          : Fedora Project

I have a workaround that should stop the panic, but it's still unlikely to work for those keys; likely due to a version mismatch. I wonder if we should upgrade the libxkbcommon on the build machines (or maybe assume that that's a dependency people will already have, but I'm nervous about that particularly for the headless installation).

That is the hard part about packaging for Linux :sweat_smile: Maybe you could try updating the library version first, and see how that works out in the preview/nightly builds

Ideally we'd fallback to our bundled libraries only if the system one is absent. We currently do the fallback using rpath=$ORIGIN/../lib. As far as I'm aware there are two versions of rpath, neither of which quite works:
* The "new" one which falls back to `rpath` if the system library cannot be found when a library is loaded directly from an application.

* The "old" one which uses `rpath` in preference to the system libraries and works when a library loads another library transitively. (this is what we use currently)
  The ideal behavior is "Use the system libraries by preference, but fallback if necessary for dependencies loaded either form the app or our other shared libraries".

That's not great.

felixsanz commented 3 months ago

for me it doesn't crash on Fn key but crash on others, see the closed issue #14670 for logs

ConradIrwin commented 3 months ago

This should be fixed by Zed v0.144.x (at least it won't crash...).

It is still unlikely that the unsupported keys work.

zed-industries / zed