Zoom 7.0.0 Linux — SIGABRT in `std::stoi` when starting desktop share

A workaround for those affected is to use the web based client: https://app.zoom.us , sharing windows / screen works perfectly.

**Follow-up — definitive root cause found. This isn't a screen-capture/PipeWire bug at all; it's GNOME custom-keybinding enumeration.**

**What Zoom does on share-init:** enumerates `/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/` and parses each entry's full dconf path. The prefix-stripping logic assumes the entry name is `customN` — when it isn't, the strip lands on the wrong `/custom` boundary (the one in `/custom-keybindings/`), producing a non-numeric tail that throws from `std::stoi`.

**Backtrace (gdb catchpoint on `__cxa_throw` for `St16invalid_argument`, with libstdc++-debuginfo installed):**

```

#0 __cxa_throw (..., typeinfo for std::invalid_argument, ...)

#1 std::__throw_invalid_argument(__s = "stoi") at functexcept.cc:78

#2..#15 ?? () in /opt/zoom/zoom ← Zoom code, no symbols

#16 g_task_return_now

#17 g_task_return

#18 reply_cb

#19..#21 g_dbus_connection_call_done

#22..#23 complete_in_idle_cb

#24 g_idle_dispatch

#25..#27 g_main_context_*

#28 QEventDispatcherGlib::processEvents

#29 QEventLoop::exec

```

So the throw happens inside a glib idle callback dispatched from a D-Bus reply, but the offending parse is on dconf data, not on the portal reply itself.

**Exact failing input** (captured by `break strtol` in gdb — last call before SIGABRT):

```

strtol("0/", base=10) ✓

strtol("1/", base=10) ✓

…

strtol("14/", base=10) ✓

strtol("-keybindings/obs-record/", base=10) ✗ throws

```

The `-keybindings/` prefix in the failing input is the smoking gun — that's literally the tail of `/custom-keybindings/` after the prefix-strip latched onto the *first* `/custom` in the path instead of the last one.

**My environment:** 15 keybindings `custom0..custom14` (created via Settings UI — all parse fine) plus one named `obs-record` (created via dconf). Crashes 100% on share, every Zoom version 6.5/6.6/6.7/7.0.

**Minimal repro:**

```bash

dconf write /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/repro/binding "'<Super>F1'"

dconf write /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/repro/command "'true'"

dconf write /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/repro/name "'Repro'"

# add the 'repro' path to the master array, then click Share in Zoom → SIGABRT

```

**Workaround:** rename any non-`customN` entries to `customN` format.

**Suggested fix:** the GSettings schema for custom-keybindings is **relocatable** — the path component is permitted to be any valid GSettings key name (`[a-z][a-z0-9-]*`). The `customN` naming is a `gnome-control-center` UI convention, not a schema contract; `dconf-editor`, scripts, and extensions all legitimately create entries with other names. Two reasonable fixes:

1. Don't parse the entry name as a number at all — treat it as an opaque string ID.

2. If you must check for the `customN` pattern, match it with a regex (`^custom(\d+)$`) on the *last* non-empty path component and skip entries that don't match, rather than `terminate()`.

This explains every observation in the original report: identical crash across Zoom versions, GPU-vendor independent, identical with `LIBGL_ALWAYS_SOFTWARE=1`, identical on XWayland — because the throw fires before any screen-capture or rendering code runs.

Good detailed report  especially the fact that you tested multiple capture modes (Original / PipeWire / Remote Control) and included logs makes this really helpful for debugging. It does sound like a regression in Zoom 7.0.0 on Wayland/Fedora rather than a hardware or multi-monitor issue, especially since the older 6.x versions reportedly work fine. Hopefully the maintainers can reproduce it using your gist and trace the std::stoi crash quickly.

Hi ​@ramon_nl ,
We’re already aware of this issue, and it has been fixed in version 7.0.5 released on May 18.
Thank you for reporting this bug.