v0.2.31 SIGSEGV when hosting Steam multiplayer lobby on Linux, isolated to SetLobbyMemberData

[jadistanbelly]

Summary

RitsuLib v0.2.31 crashes Slay the Spire 2 when entering Multiplayer -> Host -> Standard on Linux/Steam. I narrowed the native crash to the Steam lobby capability route, specifically the call to SteamMatchmaking.SetLobbyMemberData(...) through RitsuLibSteamworks.TrySetLobbyMemberData(...).

Environment

• Game: Slay the Spire 2 v0.103.2
• RitsuLib affected version: v0.2.31
• Last tested working RitsuLib version: v0.2.26
• Platform: Linux, Steam build
• Route: Multiplayer -> Host -> Standard

Reproduction

1. Install RitsuLib v0.2.31.
2. Launch the game through Steam on Linux.
3. Navigate to Multiplayer -> Host -> Standard.
4. The game crashes with SIGSEGV shortly after Steam host initialization.

I also reproduced this with only RitsuLib enabled, so it does not appear to require another mod using RitsuLib.

Observed Logs

The official v0.2.31 crash stops after Steam host initialization and before RitsuLib logs the sidecar session as bound:

[INFO] [SteamHost] Initializing Steam host. Our player id: <steam_id>

Diagnostic Narrowing

I built a few local diagnostic variants from v0.2.31:

• Force RitsuLibMobileSteamRuntime.SuppressNativeSteamIntegration => true: no crash.
• Skip only RitsuLibSidecarNativeTrailerSteamSendPatch: still crashes.
• Skip only RitsuLibSidecarSteamLobbyValidationRoute: no crash.
• Instrument RitsuLibSidecarSteamLobbyValidationRoute: crash occurs after the marker immediately before TrySetLobbyMemberData, with no matching after-marker.

Instrumented crash boundary:

[INFO] [SteamHost] Initializing Steam host. Our player id: <steam_id>
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] IsAvailable enter
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] IsAvailable before GetRawLobbyIdentifier
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] IsAvailable before TryGetNumLobbyMembers lobby=<lobby_id>
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] IsAvailable after TryGetNumLobbyMembers count=1
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] IsAvailable before TryLobbyContainsMember lobby=<lobby_id> member=<steam_id>
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] PublishLocalEvidence enter
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] TryReadSteamLobbyId before GetRawLobbyIdentifier
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] TryReadSteamLobbyId before TryGetNumLobbyMembers lobby=<lobby_id>
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] PublishLocalEvidence before TrySetLobbyMemberData lobby=<lobby_id>

Then I tested one more diagnostic build that changed only PublishLocalEvidence to skip the SetLobbyMemberData write. That did not crash and reached the hosted lobby:

[INFO] [SteamHost] Initializing Steam host. Our player id: <steam_id>
[INFO] [com.ritsukage.sts2-RitsuLib] [SteamLobbyRouteDiag] Diagnostic build: skipping SetLobbyMemberData lobby=<lobby_id>
[INFO] [com.ritsukage.sts2-RitsuLib] [Sidecar] Session bound epoch=1, netType=Host, netId=<steam_id>
[INFO] [RMP:HostBootstrap] Hosted Standard lobby via Steam with capacity 16.

Suspected Regression Area

The relevant change appears to be in the Steam integration refactor included in v0.2.31, especially commit:

0086578 feat(Steam Integration): refactor Steam-related functionality and update dependencies

That adds Platform/Steam/RitsuLibSteamworks.cs and changes RitsuLibSidecarSteamLobbyValidationRoute to use the reflection wrapper for lobby operations.

Current Hypothesis

The SIGSEGV is caused by the reflected SteamMatchmaking.SetLobbyMemberData(...) call in RitsuLibSteamworks.TrySetLobbyMemberData(...) on Linux/Steam in this game context. Managed try/catch does not catch it because the crash is native.

A possible mitigation may be to avoid the Steam lobby member-data write on affected platforms/hosts, or gate it behind an availability check that proves this specific call is safe, while keeping the other sidecar validation routes available.

[jadistanbelly]

I also have a set of sanitized logs available if useful. It includes:

• the stock v0.2.31 crash log
• an instrumented crash log showing the last marker before TrySetLobbyMemberData
• coredumpctl metadata for the SIGSEGV
• a no-crash diagnostic log where only SetLobbyMemberData is skipped

[ritsukage-local-analyzer]

Warning

此分析由 AI 自动生成，仅供开发者参考，最终判断请以人工确认为准。如有疑问建议结合本地环境进一步复现确认。

摘要

v0.2.31 在 Linux/Steam 端进入 Multiplayer → Host → Standard 时发生 SIGSEGV 崩溃，定位到 RitsuLibSteamworks.TrySetLobbyMemberData 内通过反射调用 SteamMatchmaking.SetLobbyMemberData 导致的 native 崩溃。报告者的诊断非常详尽，通过多轮对照测试已将崩溃边界精确锁定到 RitsuLibSidecarSteamLobbyValidationRoute.PublishLocalEvidence 中的 TrySetLobbyMemberData 调用。try/catch 无法捕获 native SIGSEGV，因此表现为静默崩溃。建议将 SetLobbyMemberData 写操作在 Linux 平台跳过或为 PublishLocalEvidence 增加平台安全检查。

重点结论

• 简单介绍：Linux/Steam 平台上，Slay the Spire 2 进入多人游戏主机模式时因 RitsuLib v0.2.31 的 sidecar lobby member data 写入操作触发 native SIGSEGV 崩溃。
• 可能原因：RitsuLibSteamworks.TrySetLobbyMemberData（RitsuLibSteamworks.cs:208）通过反射调用 SteamMatchmaking.SetLobbyMemberData，在 Linux 原生环境下调用约定或参数编组与运行时不兼容，导致 native 层崩溃；try/catch 仅捕获托管异常，对 SIGSEGV 无效。
• 可能解决方案：(1) 在 RitsuLibMobileSteamRuntime.SuppressNativeSteamIntegration 中加入 OperatingSystem.IsLinux() 判断，或新增单独的 Linux 抑制标志；(2) 为 PublishLocalEvidence 添加平台守卫，在 Linux 上跳过 TrySetLobbyMemberData 但保留 IsAvailable 与 TryResolve（二者均不调用 SetLobbyMemberData，报告者已验证安全）。
• 需要补充：建议提供完整的玩家日志（含 RitsuLib 初始化日志）以及 Linux 发行版/Steam Runtime 版本信息，以便确认环境差异。

展开详细分析、证据与验证

问题描述

期望行为

Multiplayer → Host → Standard 正常进入 Steam 多人游戏主机模式，sidecar session 绑定成功。

实际行为

游戏在 Steam host 初始化后立即 SIGSEGV 崩溃，日志停在 [SteamLobbyRouteDiag] PublishLocalEvidence before TrySetLobbyMemberData，之后无任何输出。

复现步骤

1. 安装 RitsuLib v0.2.31。
2. 在 Linux 上通过 Steam 启动 Slay the Spire 2。
3. 进入 Multiplayer → Host → Standard。
4. 游戏在 Steam host 初始化后崩溃。

报告者验证仅 RitsuLib 启用即可复现，无需其他依赖此库的 mod。

环境与版本

• 游戏：Slay the Spire 2 v0.103.2
• RitsuLib 受影响版本：v0.2.31
• 最后正常工作版本：v0.2.26
• 平台：Linux / Steam
• 崩溃类型：SIGSEGV（native 段错误）

日志、附件与原文摘录

诊断插入日志截断点：

[INFO] [SteamLobbyRouteDiag] PublishLocalEvidence before TrySetLobbyMemberData lobby=<lobby_id>

跳过 SetLobbyMemberData 后的成功日志：

[INFO] [SteamLobbyRouteDiag] Diagnostic build: skipping SetLobbyMemberData lobby=<lobby_id>
[INFO] [Sidecar] Session bound epoch=1, netType=Host, netId=<steam_id>

要点：崩溃精确发生在 TrySetLobbyMemberData 调用处；移除该调用后 sidecar 正常绑定。

详细分析依据

代码路径：

1. RitsuLibSidecarSteamLobbyValidationRoute.PublishLocalEvidence（Networking/Sidecar/Discovery/Routes/RitsuLibSidecarSteamLobbyValidationRoute.cs:28-36）在 sidecar 验证流程中调用 RitsuLibSteamworks.TrySetLobbyMemberData。
2. 该方法委托至 Bindings.TrySetLobbyMemberData（Platform/Steam/RitsuLibSteamworks.cs:208-218），后者通过反射调用 setLobbyMemberData(createSteamId(lobbyId), key, value)。
3. 反射绑定的方法是 SteamMatchmaking.SetLobbyMemberData(CSteamID, string, string)（同文件第 91-96 行），参数为 [cSteamId, typeof(string), typeof(string)]。

崩溃机制：第 210 行的 try/catch 只能捕获托管异常（System.Exception）。SIGSEGV 发生在 Steamworks native 层时，CLR 无法将其转换为托管异常——进程直接终止。

平台守卫缺口：RitsuLibMobileSteamRuntime.SuppressNativeSteamIntegration（Platform/RitsuLibMobileSteamRuntime.cs:13-14）当前仅覆盖 Android 和 iOS，不含 Linux。Linux 桌面 Steam 环境下 native 调用风险未被识别。

报告者对照测试总结：

测试变体	结果
SuppressNativeSteamIntegration => true	不崩溃
跳过 RitsuLibSidecarNativeTrailerSteamSendPatch	仍然崩溃
跳过 RitsuLibSidecarSteamLobbyValidationRoute 整体	不崩溃
跳过 PublishLocalEvidence 中的 TrySetLobbyMemberData	不崩溃，sidecar 正常绑定

对照结果完全收敛于 TrySetLobbyMemberData 一个调用点。

反馈规范性提醒

维度	状态	备注
复现步骤	已提供	步骤清晰，含最小复现条件
期望/实际	已提供	含日志截断点与对照测试
环境与版本	已提供	含游戏版本、RitsuLib 版本、平台
日志/附件	已提供	含诊断插桩日志的完整截断边界
标题与背景	已提供	标题精确描述了崩溃位置与平台

详细验证建议

• 在 RitsuLibSidecarSteamLobbyValidationRoute.PublishLocalEvidence 的方法开头添加 if (OperatingSystem.IsLinux()) return; 守卫，在 Linux 环境测试是否消除崩溃。
• 使用 dotnet-dump 或 gdb 在 Linux 环境捕获完整 native stack trace，确认 SIGSEGV 是否发生在 libsteam_api.so 内部的 SetLobbyMemberData 调用中。
• 检查 Steamworks.NET 在 Linux 下 CSteamID 构造函数与 SetLobbyMemberData 的调用约定是否与 Windows 有差异（例如 ulong 构造函数参数的大小/对齐）。
• 在单独的小型测试项目中，通过相同的反射绑定调用 SteamMatchmaking.SetLobbyMemberData，验证是 RitsuLib 的绑定问题还是 Steamworks.NET 本身的 Linux 兼容问题。

风险与未决

• 跳过 SetLobbyMemberData 意味着 Linux Steam 主机的 lobby member data 标记不会被发布，可能影响其他依赖此标记的 sidecar 功能——但从报告者的日志来看，核心 sidecar session 绑定在跳过写入后仍然成功。
• 目前不确定问题是 RitsuLib 的反射绑定缺陷（如参数类型或调用约定不匹配）还是 Steamworks.NET 在 Linux 下对该 API 的根本性不支持。如果 GetNumLobbyMembers 等只读反射调用正常而仅有 SetLobbyMemberData 崩溃，更可能指向 API 层面差异。
• 若 SetLobbyMemberData 在 Linux Steam 上因权限/state 限制（如未完成 lobby 创建即调用）而非平台本身不可用，可能需要调整调用时序而不是永久禁用。

---

English translation

Summary

v0.2.31 triggers a SIGSEGV crash on Linux/Steam when entering Multiplayer → Host → Standard, isolated to the reflected call to SteamMatchmaking.SetLobbyMemberData inside RitsuLibSteamworks.TrySetLobbyMemberData. The reporter's diagnostic work is thorough—through multiple controlled test variants, the crash boundary is pinned precisely to TrySetLobbyMemberData within RitsuLibSidecarSteamLobbyValidationRoute.PublishLocalEvidence. Managed try/catch cannot trap native SIGSEGV, resulting in a silent process termination. The recommended approach is to skip the SetLobbyMemberData write on Linux or add a platform safety guard to PublishLocalEvidence.

Key Takeaways

• Overview: On Linux/Steam, Slay the Spire 2 crashes with a native SIGSEGV during multiplayer host mode when RitsuLib v0.2.31 attempts the sidecar lobby member data write operation.
• Likely Cause: RitsuLibSteamworks.TrySetLobbyMemberData (RitsuLibSteamworks.cs:208) invokes SteamMatchmaking.SetLobbyMemberData via reflection; on Linux the calling convention or parameter marshaling is incompatible with the native runtime, causing a SIGSEGV. The try/catch only handles managed exceptions and is ineffective against native crashes.
• Suggested Fix: (1) Add OperatingSystem.IsLinux() to RitsuLibMobileSteamRuntime.SuppressNativeSteamIntegration, or introduce a separate Linux suppression flag; (2) Add a platform guard to PublishLocalEvidence to skip TrySetLobbyMemberData on Linux while keeping IsAvailable and TryResolve active (neither calls SetLobbyMemberData; the reporter verified both are safe).
• Information Needed: Full player logs including RitsuLib initialization output, and Linux distribution / Steam Runtime version details to confirm environment specifics.

Expand detailed analysis, evidence, and verification

Problem Description

Expected Behavior

Multiplayer → Host → Standard proceeds normally to the Steam multiplayer lobby, with the sidecar session binding successfully.

Actual Behavior

The game crashes with SIGSEGV shortly after Steam host initialization. Logs stop at [SteamLobbyRouteDiag] PublishLocalEvidence before TrySetLobbyMemberData with no subsequent output.

Reproduction Steps

1. Install RitsuLib v0.2.31.
2. Launch Slay the Spire 2 via Steam on Linux.
3. Navigate to Multiplayer → Host → Standard.
4. The game crashes after Steam host initialization.

The reporter confirms the crash occurs with only RitsuLib enabled, requiring no other dependent mods.

Environment & Versions

• Game: Slay the Spire 2 v0.103.2
• RitsuLib affected version: v0.2.31
• Last known working version: v0.2.26
• Platform: Linux / Steam
• Crash type: SIGSEGV (native segmentation fault)

Logs, Attachments, and Excerpts

Instrumented crash boundary:

[INFO] [SteamLobbyRouteDiag] PublishLocalEvidence before TrySetLobbyMemberData lobby=<lobby_id>

Successful run after skipping SetLobbyMemberData:

[INFO] [SteamLobbyRouteDiag] Diagnostic build: skipping SetLobbyMemberData lobby=<lobby_id>
[INFO] [Sidecar] Session bound epoch=1, netType=Host, netId=<steam_id>

Takeaway: The crash occurs precisely at the TrySetLobbyMemberData call; removing that call allows the sidecar to bind normally.

Detailed Analysis

Code path:

1. RitsuLibSidecarSteamLobbyValidationRoute.PublishLocalEvidence (Networking/Sidecar/Discovery/Routes/RitsuLibSidecarSteamLobbyValidationRoute.cs:28-36) calls RitsuLibSteamworks.TrySetLobbyMemberData during sidecar validation.
2. This delegates to Bindings.TrySetLobbyMemberData (Platform/Steam/RitsuLibSteamworks.cs:208-218), which invokes setLobbyMemberData(createSteamId(lobbyId), key, value) via reflection.
3. The reflected method is SteamMatchmaking.SetLobbyMemberData(CSteamID, string, string) (same file, lines 91-96), with parameters [cSteamId, typeof(string), typeof(string)].

Crash mechanism: The try/catch on line 210 only catches managed exceptions (System.Exception). When a SIGSEGV occurs in the Steamworks native layer, the CLR cannot convert it to a managed exception—the process terminates immediately.

Platform guard gap: RitsuLibMobileSteamRuntime.SuppressNativeSteamIntegration (Platform/RitsuLibMobileSteamRuntime.cs:13-14) currently covers only Android and iOS, not Linux. The risk of native calls on Linux desktop Steam was not accounted for.

Reporter's controlled test matrix:

Test variant	Result
SuppressNativeSteamIntegration => true	No crash
Skip RitsuLibSidecarNativeTrailerSteamSendPatch	Still crashes
Skip RitsuLibSidecarSteamLobbyValidationRoute entirely	No crash
Skip TrySetLobbyMemberData within PublishLocalEvidence	No crash, sidecar binds normally

All results converge on the single TrySetLobbyMemberData call site.

Issue Report Hygiene

Dimension	Status	Note
Repro steps	Provided	Clear steps with minimal reproduction condition
Expected/Actual	Provided	Includes log cutoff points and controlled tests
Environment & Version	Provided	Game version, RitsuLib version, platform
Logs/Attachments	Provided	Complete diagnostic instrumentation with crash boundary
Title & Background	Provided	Title precisely identifies crash location and platform

Verification Checklist

• Add if (OperatingSystem.IsLinux()) return; as a guard at the top of RitsuLibSidecarSteamLobbyValidationRoute.PublishLocalEvidence and test on Linux to confirm the crash is eliminated.
• Use dotnet-dump or gdb on Linux to capture a full native stack trace and confirm the SIGSEGV originates inside libsteam_api.so at the SetLobbyMemberData call.
• Check whether Steamworks.NET has documented CSteamID constructor or SetLobbyMemberData calling convention differences between Windows and Linux (e.g., ulong constructor argument size/alignment).
• In a minimal test project, call SteamMatchmaking.SetLobbyMemberData through the same reflection binding to determine whether the issue lies in RitsuLib's binding or in Steamworks.NET's Linux compatibility.

Risks and Uncertainties

• Skipping SetLobbyMemberData means Linux Steam hosts will not publish the lobby member data marker, which could affect other sidecar features that depend on it—though the reporter's logs show core sidecar session binding succeeds without it.
• It is currently unclear whether the issue is a defect in RitsuLib's reflection binding (e.g., parameter type or calling convention mismatch) or a fundamental lack of support for this API in Steamworks.NET on Linux. The fact that read-only reflected calls like GetNumLobbyMembers work but only SetLobbyMemberData crashes points toward an API-level difference.
• If SetLobbyMemberData fails on Linux Steam due to a permission/state restriction (e.g., called before lobby creation completes) rather than being inherently unavailable, the call timing may need adjustment rather than permanent disabling.

---

工具侧记录

• BAKAOLC/STS2-RitsuLib#39 · 退出码 0 · 进程 222.74s
• deepseek-v4-pro · API 220897ms · 20 轮 · ↓47197 ↑6851 · 缓存读269696 写0 · $0.5421
• MCP available: management tools exposed to Claude.

[BAKAOLC]

/r set p1 bug other wip crit

[BAKAOLC]

I have modified some content; would you mind helping me test it if you have the time?
It has now been pushed to the dev-build artifacts

/r set review

[jadistanbelly]

I have modified some content; would you mind helping me test it if you have the time? It has now been pushed to the dev-build artifacts

/r set review

dev and main releases seem to work. Previously I would crash by just navigating to Multiplayer -> Host -> Standard but now I can reach the character selection screen.

I can do some further testing later on by loading into an actual multiplayer save but I think this bug has been resolved