protonscr

steamwebhelper restarts on AT-SPI Action.GetActions due to bundled libatk-bridge a(sss) serialization bug

steamopen runtimeWeb Component
ValveSoftware/steam-for-linux#13454 · opened 2026-07-27 by proggpt920-create · updated 2026-08-10 · 3 comments · github
Pproggpt920-create 2026-07-27 github

Your system information

  • Steam client version (build number or date): 1784669098
  • Distribution: Fedora Linux 44, KDE Plasma 6.7.3 on Wayland
  • Opted into Steam client beta?: No
  • Have you checked for system updates?: Yes
  • Steam Logs: Full archive not attached because it contains unrelated identifying information. The exact relevant log excerpt is included below. A narrowly scoped and redacted excerpt can be provided if additional context is required.
  • GPU: NVIDIA GeForce RTX 4060 Laptop GPU and AMD Radeon 880M/890M
  • Steam Runtime: steamrt3c_platform_3c.0.20260618.246540
  • Bundled libatk-bridge2.0-0: 2.38.0-1
  • Host at-spi2-core: 2.60.5-1.fc44

Please describe your issue in as much detail as possible

A single standard, read-only AT-SPI org.a11y.atspi.Action.GetActions call on Steam's Chromium AT-SPI application root causes steamwebhelper to terminate. Steam automatically starts a replacement helper while the main Steam process remains running.

GetActions is specified to return a(sss): an array of three-string structures containing the localized action name, localized description, and keybinding. Instead, the D-Bus connection is closed while the response is being marshalled. The caller observes that the remote D-Bus peer disconnected, followed by Steam starting a replacement steamwebhelper.

Expected behavior

  • GetActions returns a valid a(sss) response.
  • The D-Bus connection remains open.
  • steamwebhelper continues running.

Actual behavior

  • The D-Bus peer disconnects during the call.
  • steamwebhelper terminates.
  • Steam automatically starts a replacement helper.
  • The main Steam process remains running.

The exact relevant Steam log excerpt is:

D-Bus: Array or variant type requires that type end_struct be written, but string was written.
The overall signature expected here was 'a(sss)' and we are on byte 5 of that signature.

The Steam Runtime listed above bundles libatk-bridge2.0-0 version 2.38.0-1. This matches a known upstream bug in the ATK-to-AT-SPI bridge: the affected GetActions implementation opens a three-string (sss) structure but attempts to append four strings. The upstream fix removes the extra unlocalized action name:

https://github.com/GNOME/at-spi2-core/commit/dc0dc3318171c824ba16cbb3e28780df2bda21cc

The host Fedora library is newer, but steamwebhelper loads the Steam Runtime copy at:

/usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0.0.0

Steps for reproducing this issue

  1. Start the stable Steam client and leave its desktop UI running.

  2. Resolve the AT-SPI bus address:

    AT_SPI_ADDRESS=$(gdbus call --session \
      --dest org.a11y.Bus \
      --object-path /org/a11y/bus \
      --method org.a11y.Bus.GetAddress | cut -d "'" -f 2)
    
  3. List the registered AT-SPI application roots:

    gdbus call --address "$AT_SPI_ADDRESS" \
      --dest org.a11y.atspi.Registry \
      --object-path /org/a11y/atspi/accessible/root \
      --method org.a11y.atspi.Accessible.GetChildren
    
  4. Identify the unique bus name for Steam's Chromium AT-SPI application root and assign it to STEAM_AT_SPI_BUS_NAME.

  5. Run this single direct, read-only call:

    gdbus call --address "$AT_SPI_ADDRESS" \
      --dest "$STEAM_AT_SPI_BUS_NAME" \
      --object-path /org/a11y/atspi/accessible/root \
      --method org.a11y.atspi.Action.GetActions
    
  6. Observe that the D-Bus peer disconnects and Steam automatically restarts steamwebhelper, while the main Steam process remains running.

Ssmcv 2026-08-05 github

A single standard, read-only AT-SPI org.a11y.atspi.Action.GetActions call on Steam's Chromium AT-SPI application root causes steamwebhelper to terminate. Steam automatically starts a replacement helper while the main Steam process remains running.

Is there a real-world impact to this, like perhaps the steamwebhelper crashing when you use a particular accessibility tool?

https://github.com/GNOME/at-spi2-core/commit/dc0dc3318171c824ba16cbb3e28780df2bda21cc

This is actually https://gitlab.gnome.org/Archive/at-spi2-atk/-/work_items/20, and in the steamrt3c runtime's codebase the bug is in at-spi2-atk, but a fixed version of at-spi2-atk was never released as an independent project; instead it was merged into at-spi2-core. It looks like the crash can probably be fixed by backporting that change into the steamrt3c runtime (tracked as steamrt/tasks#1105 internally).

The host Fedora library is newer, but steamwebhelper loads the Steam Runtime copy

Yes, this is working as intended: the steamwebhelper intentionally loads application-layer libraries like this one from the steamrt3c container, not from the host system, to avoid relying on specific libraries being installed on the host.

Pproggpt920-create 2026-08-08 github

Is there a real-world impact to this, like perhaps the steamwebhelper crashing when you use a particular accessibility tool?

The initial incident occurred when a desktop inspection client enumerated the system AT-SPI tree, which caused steamwebhelper to terminate and restart.

The direct GetActions call in the report was used afterward to isolate the cause. I have not reproduced this with conventional assistive technology or during normal Steam use, so the currently confirmed impact is limited to programmatic AT-SPI inspection.

Ssmcv 2026-08-10 github

The initial incident occurred when a desktop inspection client enumerated the system AT-SPI tree, which caused steamwebhelper to terminate and restart.

OK, so you saw this crash as a result of using a developer tool; and other Steam users might potentially see this crash as a result of using an assistive technology that interacts with the same interfaces, but that's unconfirmed.

I was able to reproduce the crash, and a backported fix for it is queued up for inclusion in a future Steam Client beta. (I can't predict when that will happen.)

Nothing extracted yet.