[Bug]: on android SIGSEGV when a directory contains more than two child directories

[dusk-beep]

Which fff frontend?

Neovim plugin (fff.nvim)

has logs

fff+1786859934+11285.log

Description

Bug: SIGSEGV when a directory contains more than two child directories

Which fff frontend?

Neovim plugin (fff.nvim)

has logs

FFF log attached.

Description

I'm using fff.nvim on Termux with the prebuilt binary.

FFF works when a directory contains ≤2 child directories, but consistently segfaults when a directory contains >2 child directories, regardless of nesting depth.

Reproduction

Works:

.
├── a
└── b

Crashes:

.
├── a
├── b
└── c

Also works when nested:

.
└── parent
    ├── a
    └── b

But crashes at any depth when that directory has more than two child directories:

.
└── parent
    └── child
        ├── a
        ├── b
        └── c

The crash occurs during the zlob filesystem walk:

fff_search::walk::zlob: new
=== CRASH SIGSEGV (fff) ===
fff.nvim's rust extension hit a segfault and is about to die.
=== CRASH END SIGSEGV ===

Environment

Termux
aarch64 / arm64-v8a
fff.nvim using the prebuilt binary

[dmtrKovalenko]

did it happen recently or you just installed it I indeed pushed some changes to the zlob recently and it definetely has been working before

[gustav-fff]

[triage-bot] CANNOT REPRODUCE on non-Android aarch64.

Built --features zlob (zlob 1.6.3), macOS aarch64, and walked your exact trees directly through walk_collect_files (non-git root, so SKIP_HIDDEN, same path your log hit). No segfault:

flat:   ./{a,b,c}                      -> ok
nested: ./parent/child/{a,b,c} + file  -> ok
threads = 1,2,4,8,16                   -> all clean

Your banner fires inside zlob's native walker, before fff Rust ever touches an entry:

walk_filesystem:zlob walker: fff_search::walk::zlob: new
=== CRASH SIGSEGV (fff) ===

So this is Android/bionic-specific in the zlob native code, not the fff Rust/Lua layer. Lines up with the recent bump zlob =1.6.2 -> =1.6.3 (#777, merged 2026-08-14, two days before you filed) — smells like a zlob 1.6.3 regression on the Termux aarch64 build that doesn't hit glibc/macOS.

@dusk-beep to pin it: does an older prebuilt binary from before #777 (fff with zlob 1.6.2) stop the crash? If yes it's the zlob bump.

Honk-Honk 🪿

[dusk-beep]

did it happen recently or you just installed it I indeed pushed some changes to the zlob recently and it definetely has been working before

it has worked on 0.9.* (tested on 0.9.6),but stopped after 0.10.0 till latest

[gustav-fff]

[triage-bot] ROOT CAUSE (upstream zlob), correcting my earlier guess.

Your version data pins the regression: 0.9.6 shipped zlob 1.4.1 (works), 0.10.0 shipped zlob 1.6.1 (crashes). So it is NOT the 1.6.2->1.6.3 bump (#777) I suspected — it is the earlier jump 1.4.1 -> 1.6.1 (bump #663, plus the walk rewrite #645), both landed in 0.10.0.

The segfault fires inside the native walker before fff Rust touches any entry:

fff_search::walk::zlob: new
=== CRASH SIGSEGV (fff) ===

zlob is a separate Zig/C library (github.com/dmtrKovalenko/zlob), pinned =1.6.3 in Cargo.toml:39. The >2 child directories threshold smells like the parallel dir-traversal path splitting work across threads and hitting a bionic-specific bug that glibc/macOS never hit. Cannot repro here (no Android device) and this is not fixable in the fff Rust/Lua layer — the fix belongs in the zlob native code.

@dmtrKovalenko this needs an upstream zlob fix / an Android+aarch64 regression test between 1.4.1 and 1.6.1. Out of scope for a fff-side patch.

Honk-Honk 🪿