Regression: deno 2.9 compiled binary segfaults in flatpak

[sigmaSd]

Version: Deno 2.9

minimal repro (this works with version 2.8.3)

repro-denocompile-bug.yml

app-id: io.github.sigmasd.deno-compile-repro
runtime: org.gnome.Platform
runtime-version: "50"
sdk: org.gnome.Sdk
command: hello

finish-args:
  - --socket=wayland
  - --socket=fallback-x11

modules:
  - name: hello
    buildsystem: simple
    build-commands:
      - echo 'console.log("hello from flatpak");' > main.ts
      - DENORT_BIN=$PWD/denort ./deno compile --output hello -A main.ts
      - install -Dm755 hello /app/bin/hello
    sources:
      - type: archive
        url: https://github.com/denoland/deno/releases/download/v2.9.0/deno-x86_64-unknown-linux-gnu.zip
        sha256: 96c9c73fc05ea57603bc28d8071d41e861bd40bcf2a9f849dd5969ed1a2c8498
        strip-components: 1
        only-arches:
          - x86_64
      - type: archive
        url: https://github.com/denoland/deno/releases/download/v2.9.0/denort-x86_64-unknown-linux-gnu.zip
        sha256: 04717f765622274fbefee08833953810fe2ca0a1758807f1dbc4fe8160dad851
        strip-components: 1
        only-arches:
          - x86_64

flatpak-builder --force-clean --user --install repro-build repro-denocompile-bug.yml

flatpak run io.github.sigmasd.deno-compile-repro

echo $status
139

[sigmaSd]

deepseek:

Bisect complete! The first bad commit is ab8c25425ae7db6bd88c3e61d86078d0cbcfe6f7.

Summary

Step	Commit	Index	Result
Middle	67057f921655df5b75e13c0ee3f63c93b055795c	99	✅ GOOD
Upper half	893d85bae55aa76540fef98fb18d3e0694b199cd	148	✅ GOOD
Upper half	103ad492ef5ff04cd511826e530e48f9114944f3	172	✅ GOOD
Upper half	04ac9f1b9b9359727e45285511951ce63e14c8a2	184	❌ BAD
Mid	552fd06ce914ed73a56b097c6395971c4c29eea0	178	❌ BAD
Mid	8509ae77883a90d832aa8800ba8f4317c2c499da	175	✅ GOOD
Narrow	741f4df647f8e922c55841955b33db9405db4a1b	176	✅ GOOD
Found	ab8c25425ae7db6bd88c3e61d86078d0cbcfe6f7	177	❌ BAD

PR: #35467 — chore: bump libsui to 0.16.0 by @littledivy

Root cause: The libsui bump from 0.15.0 → 0.16.0 changed how the .note.sui ELF section is appended to denort's shared library during deno compile. The old approach (0.15.0) placed the note based on file offset; 0.16.0 appends it in-place past .bss to preserve RELR relocations. The in-place manipulation of the ELF binary causes the compiled output to segfault inside the flatpak sandbox (exit 139).

[sigmaSd]

libsui bisect:

Found it! The commit that introduced the segfault is libsui commit 9c63027 - "fix(elf): preserve relative relocations by appending notes in-place (#72)".

Complete Bisect Results

Level	Version/Commit	Result
Deno v2.8.3	ba69908	✅ GOOD
Deno middle	67057f921...	✅ GOOD
Deno upper	103ad492e...	✅ GOOD
Deno bad	04ac9f1b9...	❌ BAD
Deno first bad	ab8c25425ae7db6bd88c3e61d86078d0cbcfe6f7	❌ BAD → PR #35467
libsui 0.15.0	2ceb2be	✅ GOOD (exit 0 in flatpak)
libsui .bss fix	cc8922e	✅ GOOD (exit 0)
libsui in-place	9c63027	❌ BAD (exit 139)

Root cause: libsui commit 9c63027 (#72) — "fix(elf): preserve relative relocations by appending notes in-place". This rewrote Elf::append to modify the original ELF binary in-place (grafting the note at the end) instead of round-tripping through object::build::elf::Builder. The in-place manipulation creates an ELF layout that segfaults when loaded inside Flatpak's sandbox (exit 139). The simple test binary (a trivial C printf hello) reproduces this with the sui CLI alone.

[sigmaSd]

Root cause according to DS4 flash

Root Cause

eu-strip (elfutils 0.193) from the Flatpak SDK corrupts sui-modified ELF binaries. It writes all-NULL program headers, producing an invalid binary that segfaults.

The corruption happens because:

1. sui adds a SHT_NOTE section header for .note.sui at file offset 0x4348 (vaddr 0x404348) inside a new PT_LOAD at offset 0x4000 (vaddr 0x404000)
2. The new section is discontiguous from the original allocated sections (which end at ~0x2000 file-offset / 0x403000 vaddr)
3. eu-strip tries to reconstruct program headers from section headers but cannot produce a valid PT_LOAD satisfying the ELF congruence (p_offset % align == p_vaddr % align) across the file-offset vs vaddr gap
4. It gives up and writes 15 PT_NULL entries → segfault on exec

binutils strip handles this fine because it preserves the original program headers — eu-strip (elfutils) tries to reconstruct them from sections and fails.

Fix Plan

Don't add the .note.sui section header. The PT_NOTE program header alone is sufficient for both dl_iterate_phdr (runtime) and eu-strip (which preserves PT_NOTE entries even without matching sections, as confirmed on the original binary).

Change in lib.rs, Elf::append: remove the section-header-block starting at line 1366 (if let Some((shstr_off, shstr_size)) = shstr_range { ... }). Without it:

• new_shoff stays 0 (unchanged from original)
• new_shnum stays 0
• The note survives stripping via PT_NOTE alone

This mirrors the "fully stripped" code path that already handles this case (as noted in the comment on line 1332: "A fully stripped binary has no section table to extend, and keeps the note via PT_NOTE alone.")

If you also want binutils-strip compatibility (which the .note.sui section was originally for), a follow-up fix is: place the section header table and .shstrtab inside the new PT_LOAD so eu-strip sees contiguous file-offset→vaddr coverage. But that's more complex and may not be needed — PT_NOTE is the standard runtime discovery mechanism.

[sigmaSd]

@littledivy