Error': system call

[mozzaru]

================================================================
ISSUE REPORT - OpenCode Termux release Push260828 (native/bionic)

TITLE SUGGESTION:
"opencode_1.18.21_aarch64.deb (native bionic) crashes with 'Bad
system call' (SIGSYS / exit 159) on kernel 4.19.152 (Android 11,
API 30)"

---

1. SUMMARY

---

The native (bionic) OpenCode build, version 1.18.21, from the
Push260828 release
(asset: opencode_1.18.21_aarch64.deb), fails to start on this
device with a runtime crash:

Bad system call            ./opencode --version
exit code: 159  (= 128 + 31 -> SIGSYS)

The binary cannot even print its version. In contrast, the glibc
wrapper line build (opencode-glibc 1.18.15) from the same release
works correctly and is fully functional.

---

2. DEVICE / ENVIRONMENT

---

• Platform : Termux (Android), arch = aarch64 (arm64-v8a)
• Android : 11 (SDK / API level 30)
• Kernel : 4.19.152-perf+ (安装后尝试运行显示Segmentation fault #1 SMP PREEMPT, Sep 14 2022)
• OpenCode : 1.18.21 (native bionic), 1.18.15 (glibc, works)
• Repo : https://github.com/Hope2333/opencode-termux

Note: the release notes for the native line state
"Requires Android API >= 28". This device has API level 30, which
satisfies that requirement, yet the binary still crashes.

---

3. REPRODUCTION STEPS

---

1. Download the native build:
   opencode_1.18.21_aarch64.deb
   from the Push260828 release.

2. Install (or extract) the package:
   dpkg -i opencode_1.18.21_aarch64.deb

3. Run OpenCode:
   opencode --version

Result:
Bad system call ./opencode --version
exit code: 159

Also reproduced by extracting the .deb with dpkg-deb -x and
running the unpacked binary directly (same SIGSYS crash).

---

4. EXPECTED BEHAVIOR

---

• opencode --version should print "1.18.21" and exit 0.
• The full CLI (TUI, models list, agent list) should start normally.

---

5. ACTUAL BEHAVIOR / OBSERVED SYMPTOMS

---

• Every startup attempt ends with SIGSYS "Bad system call"
  (exit 159), before any output is produced.
• Symptom is consistent (not intermittent) - 3/3 runs crashed.

---

6. DIAGNOSIS / ROOT-CAUSE HYPOTHESIS

---

SIGSYS / "Bad system call" occurs when a process invokes a syscall
that the kernel does not implement or the seccomp policy blocks.

Since API level (30) satisfies the documented ">= 28" requirement,
the most probable cause is that the native binary invokes a newer
syscall (e.g. faccessat2, openat2, clone3, or similar) that
the older 4.19.152 kernel on this device does not provide.

The corresponding glibc build (opencode-glibc 1.18.15) runs fine on
the exact same device, which strongly suggests the difference is in
how the native binary interacts with the kernel/syscalls rather than
a generic incompatibility with the device.

---

7. IMPACT

---

• The "native bionic mainline" build (which the release notes mark as
  the recommended mainline going forward) cannot be used on this
  device.
• Users on older Android 11 / kernel 4.19 devices are forced back to
  the now-legacy glibc wrapper line (1.18.15), which caps their
  OpenCode version at 1.18.15.

---

8. REQUESTED ACTION / QUESTION

---

1. Is there a known kernel/API requirement (beyond "API >= 28") for the
   native build, e.g. a specific minimum kernel version, or a specific
   set of syscalls that must be available?
2. Would it be possible to either:
   a) fall back to older syscalls (or use syscall(SYS_* ) shims)
   for kernels < 5.x, or
   b) publish the glibc line at the same version (1.18.21) so users
   on older kernels are not stuck at 1.18.15?

---

9. ADDITIONAL INFO

---

• Checksum (sha256) of the tested asset, verified against
  SHA256SUMS.txt:
  opencode_1.18.21_aarch64.deb
  = 3bc040e95b49da085fe280e08b46558df5839d1d06ab5304c45ac98cf2508e76
• The native binary is an aarch64 bionic ELF; the static string
  "/lib64/ld-linux-x86-64.so.2" present in the file belongs to the
  bundled OpenSSL and is NOT the binary interpreter (the binary is
  genuinely aarch64).
• strace is not available on this Termux environment and the kernel
  logs (dmesg) are not readable without root, so the exact offending
  syscall number could not be captured on-device.

================================================================
END OF REPORT

[Hope2333]

Thanks for the thorough report — your diagnosis is correct.

Root cause: Android's zygote seccomp filter (API ≤ 14 / kernel 4.19) does not include close_range (syscall nr 436) in its allow-list. When Bun calls close_range(4, ~0U, CLOSE_RANGE_CLOEXEC) during startup fd hygiene, the kernel delivers SECCOMP_RET_TRAP → SIGSYS (exit 159). This is the same root cause as upstream oven-sh/bun#30766, first reported on Android 12 / SDK 31.

What RC1 fixes: The Push260903rc1 native package ships libopencode-crhandler.so — a self-activating seccomp rescue layer with two complementary mechanisms:

1. SIGSYS handler (SA_SIGINFO): intercepts the signal at delivery time, advances the program counter past the trapping svc instruction (pc += 4), and returns -ENOSYS in x0. This covers inline-svc sites that no PLT interposition can reach (same semantics as upstream #39775 / #39060).

2. PLT interposers for syscall() and close_range(): short-circuit nr 436 at call sites before the kernel ever sees it. This is the only layer that rescues bun's forked child processes, which inherit no usable SIGSYS disposition.

The shim is wired as the first DT_NEEDED entry in the binary's dynamic section via tools/transplant/crhandler_patch.py — bionic's symbol lookup order means the PLT interposition wins over libc. No LD_PRELOAD, no environment variables, no user action required.

Immediate fallback (if you want to test before RC1): The earlier native-beta-260826 release provides a standalone LD_PRELOAD shim (libopencode-crshim.so, PLT-only, no handler layer):

curl -fsSL https://github.com/Hope2333/opencode-termux/releases/download/native-beta-260826/libopencode-crshim.so -o $PREFIX/lib/libopencode-crshim.so
export LD_PRELOAD=$PREFIX/lib/libopencode-crshim.so

Note: this older shim only covers PLT call sites — bun's spawn-child path (inline svc) may still SIGSYS. The RC1 crhandler covers both layers.

Please test RC1:

# https://github.com/Hope2333/opencode-termux/releases/tag/Push260903rc1
# Asset: opencode_1.18.21_aarch64.deb (native, with crhandler shim)
dpkg -i opencode_1.18.21_aarch64.deb
opencode --version

To help us close this issue, please report:

1. Your Android version (you mentioned API 30 — confirmed Android 11)
2. Whether RC1 native resolves the SIGSYS crash

If it still fails, please share the output and we'll investigate further.

[mozzaru]

========================================
OPENCODE NATIVE RC2 - TEST REPORT

Date: 2026-09-04
Tester: User (Termux)
Package: opencode_1.18.27_aarch64.deb (native, RC2)

---

DEVICE INFORMATION

Platform: aarch64
Android Version: 11
API Level: 30
Kernel: (Termux environment)

---

TEST RESULT: SUCCESS

Command: opencode --version
Output: 1.18.27
Status: No SIGSYS crash, no SECCOMP_TRAP, no exit 159

---

ANALYSIS

Root Cause (before fix):
Android's zygote seccomp filter (API <= 14 / kernel 4.19)
does not include close_range (syscall nr 436) in its allow-list.
When Bun calls close_range(4, ~0U, CLOSE_RANGE_CLOEXEC) during
startup fd hygiene, the kernel delivers SECCOMP_RET_TRAP -> SIGSYS
(exit 159).

What RC2 Fixes:
The native package ships libopencode-crhandler.so — a self-activating
seccomp rescue layer with two complementary mechanisms:

1. SIGSYS handler (SA_SIGINFO): intercepts the signal at delivery
   time, advances the program counter past the trapping svc
   instruction (pc += 4), and returns -ENOSYS in x0.

2. PLT interposers for syscall() and close_range(): short-circuits
   nr 436 at call sites before the kernel ever sees it.

The shim is wired as the first DT_NEEDED entry in the binary's
dynamic section. No LD_PRELOAD, no environment variables,
no user action required.

---

VERDICT

[PASS] opencode native RC2 works on Android 11 / API 30
[PASS] SIGSYS crash resolved
[PASS] No manual configuration needed

========================================
END OF REPORT

[mozzaru]

and how to install this in termux?
You can't use buns
plugin https://github.com/code-yeongyu/oh-my-openagent

[mozzaru]

Crash ?
???:?:?: 0x5de3484893 in ??? (/data/data/com.termux/files/usr/bin/opencode) ???:?:?: 0x5de300a12f in ??? (/data/data/com.termux/files/usr/bin/opencode)
???:?:?: 0x5de3008c63 in ??? (/data/data/com.termux/files/usr/bin/opencode)
???:?:?: 0x5de28925e3 in ??? (/data/data/com.termux/files/usr/bin/opencode) ???:?:?: 0x5de2897b4b in ??? (/data/data/com.termux/files/usr/bin/opencode) ???:?:?: 0x5de2f79fdb in ??? (/data/data/com.termux/files/usr/bin/opencode)
???:?:?: 0x5de2ef51c7 in ??? (/data/data/com.termux/files/usr/bin/opencode)
???:?:?: 0x5de2ef2fc7 in ??? (/data/data/com.termux/files/usr/bin/opencode)
???:?:?: 0x5de21a9e8b in ??? (/data/data/com.termux/files/usr/bin/opencode) ???:?:?: 0x71a0ef3a5f in ??? (/apex/com.android.runtime/lib64/bionic/libc.so) ???:?:?: 0x5de21a986b in ??? (/data/data/com.termux/files/usr/bin/opencode)
Aborted

Deterministic SIGABRT crash on pure-android branch — likely TLS/Scudo heap corruption, not pointer-tagging

Environment

• Branch: pure-android
• Device: Android (Bionic libc, /system/bin/linker64 interpreter)
• Binary: opencode (glibc ELF wrapped via bun-termux-loader, userland-exec)
• Dependencies installed: glibc, openssl-glibc (per README instructions)

Symptom

opencode crashes with Aborted after a short period of use (not immediately on
startup). The crash is fully deterministic — repeated runs abort at the exact
same relative code offset every time, only shifted by ASLR.

Investigation performed

1. Captured native stack traces across multiple crash occurrences. Verified via
   offset diffing (subtracting the lowest frame address from each frame) that all
   frames match exactly across separate runs — confirming a deterministic bug,
   not memory corruption from an unrelated random source.

2. Attached gdb (gdb -q --args opencode, run, thread apply all bt) at the
   moment of SIGABRT. Findings:

   • Most background threads (Helper/HeapHelper/JITWorker/Bun Pool/etc.) are idle,
     parked in epoll_pwait — normal, not the crash site.
   • Thread 1 ("opencode", main thread) is the actual crash site:

     Thread 1 (Thread 0x7bf8 (LWP 31736) "opencode"):
     #0  0x0000007f07b9307c in ?? ()
     #1  0xfffe000000000002 in ?? ()
     Backtrace stopped: previous frame identical to this frame (corrupt stack?)
     

   • $pc for the crashing frame does not land in the opencode binary's
     .text segment (r-xp mapping of /data/data/com.termux/files/usr/bin/opencode).
     It lands inside anonymous heap memory (in the mimalloc/heap allocator
     address range per /proc/<pid>/maps).
   • Frame 安装后尝试运行显示Segmentation fault #1 contains 0xfffe000000000002 — not a valid pointer. This bit
     pattern is consistent with a truncated/corrupted tagged pointer, i.e.
     the classic Bionic "software heap tagging" tag-mismatch symptom (see
     https://source.android.com/devices/tech/debug/tagged-pointers), OR
     Scudo allocator metadata corruption from a TLS layout mismatch.

3. Tested JSC_useJIT=0 — no change, crash identical (ruled out JIT-codegen
   as the direct cause, though JS engine's use of JIT/heap layout may still be
   an indirect factor).

4. Tested LD_PRELOAD=libtagfix.so (binary pulled from
   guysoft/opencode-termux v0.2.1 release asset) — loaded successfully, no
   linker errors, but crash is byte-for-byte identical (verified via offset
   diff against the pre-preload crash). This strongly suggests the root cause
   is not simply Bionic's pointer-tagging tag-mismatch (which libtagfix.so
   is designed to suppress by disabling heap tagging via
   mallopt(M_BIONIC_SET_HEAP_TAGGING_LEVEL, ...) before JSC init) — because
   that specific mitigation had zero effect on this binary.

Hypothesis

guysoft/opencode-termux's README documents a TLS alignment fix required
for any Bun binary running under Bionic:

Without this, the Zig linker emits PT_TLS p_align=8, causing TLS variables
to overlap with Bionic's Thread Control Block slots (TPIDR+0..63),
corrupting scudo allocator state and crashing on first allocation.

This branch (pure-android) does not cross-compile Bun for Android — it wraps
the unmodified upstream glibc-linked Bun binary via bun-termux-loader's
userland-exec. If the TLS section layout emitted for the glibc target doesn't
align correctly once the binary is running under Bionic's threading/TCB
implementation (via the userland-exec trick), this could produce exactly the
kind of Scudo/heap corruption I'm observing — independent of Bionic's
pointer-tagging feature, which is why libtagfix.so had no effect.

Ask

• Is TLS segment alignment/layout something bun-termux-loader's userland-exec
  accounts for when jumping into glibc's ld.so? If not, this may be the
  actual root cause rather than pointer-tagging.
• Given libtagfix.so doesn't help here, is there a known workaround, or is
  this fundamentally a limitation of the "wrap unmodified upstream binary"
  approach vs. guysoft's "cross-compile Bun natively for Android" approach
  (which patches this at the Zig/CMake build level)?

Reproduction data available on request

• Full /proc/<pid>/maps dump at crash time
• gdb thread apply all bt output (all 25 threads)
• Disassembly around crash offset in libc.so (confirmed as an
  __epoll_pwait-adjacent idle thread, unrelated to the actual crash — the
  real crash site is in Thread 1 as noted above)
• Offset-diff script confirming deterministic crash location across runs

[Hope2333]

Thank you — this report is exceptionally high quality. The gdb attach, the multi-run offset diffing, the libtagfix.so control experiment, the JIT exclusion… that is textbook-grade on-device forensics, and we genuinely appreciate the time you put into it.

A quick status sync — your reports all landed on issues we independently found and fixed during our own RC stage:

1. SIGSYS (close_range / seccomp): your diagnosis matches ours exactly. During RC we reproduced it ourselves and shipped a dual-layer fix (the self-activating libopencode-crhandler.so shim + DT_NEEDED[0] hardening). It is now included in the formal release Push260906 (v1.18.15-26 v1.18.27, current Latest) across all 13 versions. Your RC2 retest (1.18.27 passing, no SIGSYS) matches our own on-device verification — thanks again for that.

2. Deterministic SIGABRT / TLS alignment on the wrapped (pure-android) line: your TLS-alignment hypothesis was directionally spot-on — and it is exactly the architectural question that drove our RC-stage decision: the bun-termux-loader wrap path (unmodified upstream glibc binary via userland-exec) is now demoted to appendix maintenance and is no longer the mainline. The mainline is the native bionic revived line (direct ELF surgery, no userland-exec wrapper at all), and the glibc appendix was recast as a self-contained composite that no longer requires the system glibc / openssl-glibc packages (the two deps you installed per the old README can be uninstalled). On the Push260906 mainline packages, this crash path should be gone entirely.

3. oh-my-openagent: yes, it works — we use it in our current workflow. Recommended install: the opencode plugin command (verified working on both runtime lines — the native mainline and the glibc appendix); after install, let the agent configure it according to the docs (docs/plugin-management.md). Local file:// registration still works as a fallback, but the plugin command is the better-managed path. Install/migration guide for the release itself: docs/dual-track-install.md.

If you feel like doing one more round on the formal release: your repro data (the maps dump, the full gdb bt, the offset-diff script) is exactly the kind of real-device evidence we lack — if anything still reproduces on Push260906, please keep posting in this format and we will follow up. Thanks again for reports of this caliber — they are very welcome here.

[mozzaru]

besides oh-my-openagent
What plugin or harness is good for review, refactor, debug??

The problem is using oh-my-openagent, if you use a custom provider like glm-5.3-flash, the Oracle review error

[Hope2333]

Plugins/harness for review / refactor / debug:

oh-my-openagent (OMO) is the harness we use for exactly those workflows — no extra plugin needed:

• Review: OMO's oracle agent (read-only, high-quality reasoning consultant) plus the sisyphus orchestrator cover architecture review and post-change review.
• Refactor / debug: oracle for root-cause analysis and design tradeoffs, parallel explore agents for codebase reconnaissance, execution agents (hephaestus/atlas) for carrying out the change.

On the Oracle error with a custom provider (glm-5.3-flash):

That's a model-tier mismatch, not an OMO bug. Oracle's prompts are long (full-file context + review rubric) and reasoning-heavy; flash-tier models like glm-5.3-flash often fail or degrade on them. OMO supports per-agent model assignment in ~/.config/opencode/oh-my-openagent.json:

{
  "agents": {
    "oracle": {
      "model": "<strong-reasoning-model-id>",
      "fallback_models": ["<second-strong-model-id>"]
    },
    "explore": {
      "model": "<flash-model-id>"
    }
  }
}

That's the split we run ourselves: strong models on oracle/sisyphus (quality tier), flash models on explore/librarian/execution agents (throughput tier). Keep glm-5.3-flash for retrieval/execution work and give oracle the strongest model your provider offers. If it still errors with a strong model, check the provider's context-limit settings in opencode.json — Oracle's context is large and some custom providers reject it.

[mozzaru]

I did a review just asking for Oracle, and the results seemed like the reviewer was not late, there were assumptions, so I was confused about using the free model and the results were like that

Do you always review full reviews??

Kan oracle for review, then sisyphus For others so

For example, asking for a review or consultation from Oracle, that's what I do,

Btw is there a good free model??
hehe🗿