v0.4.5 regression: bash exits immediately with code 0, no output

[Bahtya]

问题描述

v0.4.5 中 bash 启动后立即以 exit code 0 退出，终端没有任何输出。v0.4.3 没有此问题。

复现

Hermux 调用：

session_id = vproc_ffi_create_session();
vpid = vproc_ffi_create_process(session_id, "/path/to/bash", argv, envp, pts, pts, pts);

Logcat

08:15:45.250  vproc: created session 3
08:15:45.250  vproc: self-test skipped (probe=ok)
08:15:45.260  vproc: virtual process created vpid=1 session=3 ptm=143
08:15:45.271  waiter: entering waitFor pid=1 sessionId=3
08:15:45.271  vproc: run_until_exit_s(vpid=1) returned 0
08:15:45.271  vproc: destroying session 3

从创建到退出仅 ~20ms，bash 没有产生任何输出到 PTY。

根因分析

v0.4.4/v0.4.5 新增的 setsid() 可能导致：

• bash 启动后发现自己不是前台进程组的一部分，直接退出
• 或者 setsid() 后 PTY slave 的 fd 连接断了（bash 的 stdin 变成无效 fd）
• bash 以交互模式启动时如果无法获得 controlling terminal，会直接 exit(0)

与 v0.4.4 的 SIGSEGV 不同（v0.4.4 在 set_signal_handler 崩溃），v0.4.5 改为了静默退出。

影响对比

• v0.4.3: bash 正常工作，有 job control 警告
• v0.4.4: bash SIGSEGV 崩溃
• v0.4.5: bash 立即退出，无输出

建议

setsid() 在 vproc 协程环境中可能无法正确工作。可能需要：

1. 在 vproc 层面模拟 session/controlling terminal 语义，而非调用真正的 setsid()
2. 或者让 setsid() 成为可选的，通过参数控制是否启用
3. 或者让 vproc 在 setsid 后重新打开 PTY slave fd 并传递给 bash

相关

• bash: cannot set terminal process group / no job control when using create_process_s with PTY #46 (job control issue)
• v0.4.4 regression: bash SIGSEGV in set_signal_handler after setsid() #48 (v0.4.4 SIGSEGV)
• 建议: 为每个 TerminalSession 创建独立的 vproc session 以支持真正的并发 hermux#571

[Bahtya]

补充诊断信息

v0.4.4/v0.4.5 变更分析

v0.4.4 (PR #47): 将 setsid, tcsetpgrp, tcgetpgrp, getpgrp, pipe2 添加到 GOT patching 列表。这些符号的 interceptor 已在 preload.rs 中存在，只是 GOT patching 没有路由到它们。

v0.4.5 (PR #48): 修复 dup/dup2 — 当源 fd 是 Vfd::Real 时，调用真实的 kernel dup/dup2，而不是只更新虚拟 fd table。这修复了 bash 的 dup2(2, 255) 后 tcgetattr(255) SIGSEGV。

v0.4.5 下 bash 立即退出的详细 log

08:15:45.250  vproc: created session 3
08:15:45.250  vproc: self-test skipped (probe=ok)
08:15:45.260  vproc: virtual process created vpid=1 session=3 ptm=143
08:15:45.271  waiter: entering waitFor pid=1 sessionId=3
08:15:45.271  vproc: run_until_exit_s(vpid=1) returned 0
08:15:45.271  vproc: destroying session 3

从创建到退出 ~20ms，bash 没有写任何数据到 PTY master（InputReader 没有收到任何数据）。

可能的原因

1. setsid interceptor 行为问题: v0.4.4 将 setsid 加入 GOT patching，但 vproc 的 setsid interceptor 在协程上下文中可能返回了错误（如 EPERM），导致 bash 认为无法控制 terminal 并选择退出
2. tcsetpgrp 失败导致 bash 退出: bash 调用 tcsetpgrp 失败后，在某些情况下会 exit(0) 而不是继续运行
3. fd 传递问题: v0.4.5 的 dup2 修复后，dup2(2, 255) 创建了 real kernel fd 255，但这个 fd 号可能和 bash 期望的不一致，导致 stdin/stdout 检查失败

建议的调试方向

1. 在 setsid interceptor 中添加 log，看它返回了什么值
2. 在 tcsetpgrp interceptor 中添加 log，看它是否被调用以及返回值
3. 检查 bash 启动时 stdin (fd 0) 是否是有效的 PTY slave — v0.4.5 的 dup2 修复可能导致某些 fd 被意外关闭或替换

[Bahtya]

新发现：v0.4.5 GOT patching 影响运行中的旧 session

详细证据

Session 3 (v0.4.5 新创建): bash 立即退出 exit code 0，无输出（已报告）

Session 2 (v0.4.3 创建的旧 session): 在 session 3 创建后约 4 分钟收到 SIGHUP (signal 1) 退出。

排除其他原因：

• Hermux Java 层只发送 SIGKILL（Os.kill(mShellPid, OsConstants.SIGKILL)），不发送 SIGHUP
• App 一直在前台（logcat 中 08:15-08:19 之间没有任何 visibilityChanged/onStop/onPause 事件）
• 不是 Android 系统杀的

根因：GOT patching 是进程级操作

patch_got_for_loaded_binary() 修改的是所有已加载 ELF 的 GOT 表。当 v0.4.5 的 libvproc.so 被 dlopen 后：

1. vproc_ensure_loaded() 执行 dlsym 加载新符号
2. 但 patch_got_for_loaded_binary() 实际上在 bash 被 load 时 就执行了 — v0.4.4 新增的 setsid/tcsetpgrp/tcgetpgrp interceptor 在 bash dlopen 时被注入到 bash 的 GOT 表
3. 如果 session 2 的 bash 已经在运行，而这些 interceptor 的行为和 bash 启动时 v0.4.3 的行为不同，就会导致运行中的 bash 异常

影响

这意味着 v0.4.4/v0.4.5 不能热升级 — 如果 app 已经有运行中的 vproc session，加载新版 libvproc.so 后 GOT patching 会影响已有的 bash 进程。需要 app 完全重启才能安全升级。

建议

1. 在 vproc 中考虑 GOT patching 的兼容性 — 新增的 interceptor 应该对旧 session 透明
2. 或者让 setsid/tcsetpgrp 等 interceptor 只在特定条件下生效（比如检查当前是否在 vproc session 的 driver thread 中）
3. 或者提供 API 让 Hermux 在加载新版本前先销毁所有旧 session

[Bahtya]

v0.4.6 测试结果：仍有问题

SIGSEGV (PAC related)

崩溃报告显示：

signal=SIGSEGV (11)
si_addr=0x7bf98e5af0  si_code=1
PAC=1  MTE=1
Backtrace:
  #00  0x7f693d5d6c
  #01  0x7f940d7848
  #02  0x2157c2546d4a0

si_addr 不是 NULL（0x7bf98e5af0），PAC=1 表明可能是 Pointer Authentication 签名验证失败。这在协程上下文切换（longjmp/setjmp）时常见 — PAC 会验证函数指针和返回地址的签名，如果协程跳转破坏了签名就会 SIGSEGV。

Session 4: exit code 127

vproc: run_until_exit_s(vpid=1) returned 127
vproc: destroying session 4

bash 以 exit code 127 退出（command not found）。其他 session (2, 3) 正常运行（watchdog heartbeat 持续）。

设备信息

ARM64, PAC=1 (HWCAP_PACA bit 30), MTE=1 (HWCAP_MTE bit 18), Seccomp=2 (filter mode)

[Bahtya]

v0.4.6 新发现：所有 session 同时以 exit code 127 死亡

之前报告了 session 4 以 code 127 退出。现在发现 所有 session（1, 2, 3）在 9ms 内同时以 code 127 死亡，这不可能是个别 bash 命令失败。

时间线（Hermux v2.5.27 + vproc v0.4.6, PID 8690）

09:06:55 ~ 09:09:07  Sessions 1, 2, 3 正常运行（watchdog 心跳持续递增）
09:09:30.155  TID 8847  run_until_exit_s(vpid=1) returned 127  → destroying session 1
09:09:30.157  TID 9718  run_until_exit_s(vpid=1) returned 127  → destroying session 3  (+2ms)
09:09:30.164  TID 9557  run_until_exit_s(vpid=1) returned 127  → destroying session 2  (+9ms)
09:09:30.178  Java: Process exited (code 127) x3

三个 waiter 线程（TID 8847, 9718, 9557）几乎同时返回 127，说明 vproc 内部发生了级联失败。

关键证据

1. 不是 bash 正常退出 — bash 的 127 是 "command not found"，不可能 3 个 session 同时执行错误命令
2. Hermux 进程本身没有崩溃 — crash buffer 中无 PID 8690 的记录
3. hermes Python 子进程随后 SIGABRT：

   Fatal signal 6 (SIGABRT) in tid 9783 (hermes)
   Abort message: 'Pointer tag for 0x6f5b457840 was truncated'
   PAC enabled keys: PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY (all 4)
   PR_TAGGED_ADDR_ENABLE = 1
   

4. run_until_exit_s 返回 127 是 vproc 内部错误码，不是 bash 的退出码

猜测

• run_until_exit_s 在 vproc 内部遇到错误时返回 127
• 可能是 GOT patching 导致的 libc 函数调用异常，触发所有 session 的级联崩溃
• PAC/MTE 环境下 coroutine context switch 可能破坏了签名/标签

设备信息

• ARM64, PAC=1 (all 4 keys), MTE=1, PR_TAGGED_ADDR_ENABLE=1
• Android 16 (BP2A.250605.031)
• vivo PD2419

[Bahtya]

v0.4.7 Regression: 进程立即死亡，无 tombstone（比 v0.4.6 更严重）

v0.4.7 的 BTI 修复导致 Hermux 进程无法启动，连续 3 次尝试都在 Activity 创建后 ~300ms 内死亡。

时间线

PID 32651（第1次尝试）:

10:10:08.318  am_proc_start (preStart)
10:10:08.539  wm_on_create_called (TermuxActivity, 37ms)
10:10:08.549  wm_on_resume_called
10:10:08.627  notification_enqueue (foreground service)
~10:10:09     进程死亡

PID 601（第2次尝试）:

10:10:09.770  am_proc_start (preStart)
10:10:09.931  wm_on_create_called (TermuxActivity, 33ms)
10:10:09.939  wm_on_resume_called
~10:10:10     进程死亡

PID 1501（第3次尝试）:

10:10:11.322  am_proc_start (top-activity)
10:10:11.447  wm_on_create_called (TermuxActivity, 31ms)
10:10:11.454  wm_on_resume_called
10:10:11.533  notification_enqueue (foreground service)
10:10:11.578  viewroot_draw_event (首帧绘制完成)
10:10:11.622  am_proc_died (距首帧仅 44ms)

关键发现

1. 无 tombstone — crash buffer 中 3 个进程均无记录

   • 排除 SIGSEGV/SIGABRT（会生成 tombstone）
   • 可能是 SIGKILL 或 seccomp 违规

2. 所有进程在终端 session 创建时死亡

   • 首帧绘制完成后 44ms 内死亡
   • 这正是 JNI createSubprocess → dlopen libvproc.so → create_session 的时机
   • v0.4.7 添加的 bti c 指令或 ret 修改可能在 dlopen 或初始化时触发问题

3. v0.4.6 → v0.4.7 回归对比:

   版本	表现
   v0.4.6	进程存活，session 运行数分钟后级联 exit 127
   v0.4.7	进程无法存活超过 300ms

4. v0.4.7 是比 v0.4.6 更严重的回归

设备信息

• ARM64, PAC=1 (all 4 keys), MTE=1, Seccomp=2 (filter mode)
• Android 16 (BP2A.250605.031)
• vivo PD2419
• PR_TAGGED_ADDR_ENABLE=1

建议

v0.4.7 的 bti c + ret 修改可能在以下方面引入了问题：

1. bti c 指令在 non-BTI-aware linker 上可能被误解
2. ret 替代 br x11 可能在某些 context 下破坏了 coroutine 约定
3. 需要检查是否有 seccomp filter 阻止了新指令的执行

[Bahtya]

v0.4.8 测试结果：dlopen 和 create_session 成功，但 create_process_s 时进程死亡

v0.4.8 比 v0.4.7 好很多——不再因为 BTI 属性导致立即崩溃。现在 dlopen 成功、session 创建成功，但在 create_process_s 阶段进程死亡。

时间线（PID 15512, Hermux v2.5.29 + vproc v0.4.8）

10:38:40.084  dlopen("libvproc.so", RTLD_NOW) — succeeded
10:38:40.085  dlopen succeeded, resolving symbols
10:38:40.085  native crash signal handler installed (SIGSEGV/SIGABRT/SIGBUS/SIGILL)
10:38:40.085  per-session API resolved:
              create_session=0x7c0d33608c
              destroy_session=0x7c0d3365f8
              create_process=0x7c0d3353a4
              run_until_exit=0x7c0d3380b8
              vpid_exists=0x7c0d338c2c
10:38:40.085  created session 1
10:38:40.085  vproc: self-test skipped (probe=ok)
              ← 此处应该是 create_process_s(bash) →
10:38:40.120  am_proc_died [0,15512,com.hermux,0,2]

进程在 session 创建后 35ms 死亡，无 tombstone。

关键发现

1. dlopen 成功 — v0.4.8 不再有 BTI 属性问题
2. Session 1 创建成功 — create_session() 返回 1（非零）
3. Self-test 通过 — probe=ok
4. 无 create_process_s 日志 — 进程在调用 create_process_s 时或之前死亡
5. 无 tombstone — 说明不是 SIGSEGV/SIGABRT，可能是 SIGKILL 或 signal handler 调用了 _exit()

多次尝试都失败

PID	启动时间	存活时间	死亡原因
14855	10:38:16	526ms	exit 525, reason 19
15512	10:38:30	~10s	exit 0, reason 2 (到达 vproc create_session)
15917	10:38:43	~3s	被 16051 替代
16051	10:38:46	~?	无 tombstone

猜测

create_process_s 内部执行 GOT patching（patch_got_for_loaded_binary），修改进程内所有已加载 ELF 的 GOT 表。在 PAC=1 环境下，GOT 表的地址可能带有 PAC 签名，修改这些条目会导致 PAC 验证失败 → SIGSEGV → vproc signal handler 捕获 → 进程退出。

或者 GOT patching 修改了 signal handler 本身的 GOT 条目，导致无限循环。

设备

ARM64, PAC=1, MTE=1, Android 16, vivo PD2419

[Bahtya]

v0.4.9 测试结果：与 v0.4.8 完全相同，create_process_s 时进程死亡

v0.4.9 将 inline hooks 改为 GOT patching（libc exit/execve），但崩溃点不变：create_process_s 时进程死亡，无 tombstone。

时间线（PID 17394, Hermux v2.5.30 + vproc v0.4.9）

11:40:12.219  dlopen succeeded
11:40:12.219  native crash signal handler installed
11:40:12.219  per-session API resolved (symbols ok)
11:40:12.219  created session 1
11:40:12.219  self-test skipped (probe=ok)
              ← create_process_s 被调用，但无后续日志 →
11:40:12.257  am_proc_died [0,17394,com.hermux,0,2]

session 创建后 38ms 死亡，无 tombstone。与 v0.4.8 完全一致。

根因分析：GOT patching 在 PAC=1 设备上根本不工作

回顾整个版本历史：

• v0.4.3：无 GOT patching → 正常工作
• v0.4.4~v0.4.9：都有 GOT patching → 全部崩溃

v0.4.9 的 patch_libc_got() 和之前的 patch_got_for_loaded_binary() 虽然技术实现不同（data page vs code page），但在 PAC=1 设备上面临相同问题：

GOT 条目包含 PAC 签名的函数指针。当 vproc 写入新的 GOT 条目时，新值没有正确的 PAC 签名。下次调用该函数时，CPU 验证 PAC 签名失败 → SIGSEGV。由于 vproc 安装了 signal handler，它可能捕获 SIGSEGV 后直接 _exit() — 这解释了为什么没有 tombstone。

建议

1. 在 PAC=1 设备上禁用 GOT patching — 可以通过 hwcap 检测 HWCAP_PACA（bit 30）来决定
2. 或者为 GOT patching 添加 PAC 感知 — 写入 GOT 条目前用 pacia/pacda 重新签名
3. 短期回退方案：提供一个无 GOT patching 的构建变体（等同于 v0.4.3 行为）