ASan/UBSan‑instrumented Harbour crashes during self‑build on Termux/ARM64 (clang)

[bertrandsoullier]

When Harbour is rebuilt with AddressSanitizer/UndefinedBehaviorSanitizer
on Termux/ARM64, the ASan‑instrumented harbour binary crashes while
compiling harbinit.prg. The build aborts before installation completes.

This report is separate from my other ticket to keep issues focused.

Environment

• ARM64 (aarch64)
• Android 15 / Termux
• clang toolchain
• Harbour 3.2.0dev (59f2c65)

Build flags

HBBUILDDEBUG=yes
HBBUILDOPTIM=no
HBUSERCFLAGS="-fsanitize=address,undefined -g"
HBUSERLDFLAGS="-fsanitize=address,undefined"

Output during build

../../../../../bin/linux/gcc/harbour ../../../harbinit.prg
-i../../../../../include -n1 -q0 -w3 -es2 -kmo -i-

==6933==WARNING: external symbolizer didn't start up correctly!
make[3]: * [harbinit.c] Broken pipe
make[2]: * [../../config/lib.mk:68: descend] Error 2
make[1]: * [../config/dir.mk:71: vm] Error 2
make: * [config/dir.mk:71: src] Error 2

Notes

• The crash occurs inside the ASan‑instrumented compiler itself.
• It happens before the instrumented harbour binary is installed.
• Disabling symbolization (ASAN_OPTIONS="symbolize=0") does not prevent the abort.
• No .ppo writing or file‑system race involved.

Expected

Harbour should be able to self‑compile under ASan/UBSan, or at least
fail with a diagnostic instead of a broken pipe.

Actual

The compiler aborts while processing harbinit.prg.

Request

Could this be investigated as a potential undefined‑behaviour hotspot
triggered by clang/ASan on ARM64?
I can run additional builds, provide logs, or test patches if needed.

[alcz]

While the issue may be valid, how one can be sure, that Harbour that crashes, not the attached instrumentation library? Harbour is compiled by multitude of different C compilers and no fatal memory corruption disturbing build process happens (incl. various ARM64 instances).
If you try to debug with advanced tools, please continue at will. Especially target for answers, not multiplying doubts: expecting guidance and requesting investigations from someone else. I mean, one can expect guidance for sure, but this is kind of a deep-dive. Thank you.

[bertrandsoullier]

Thanks for the feedback.

I understand your point about the instrumentation library possibly being
involved. To clarify the situation on my side:

• The crash happens at the moment the ASan‑instrumented harbour binary
  is invoked to compile harbinit.prg.
• The process that aborts is harbour itself (PID shown by ASan), not
  the build system or an external tool.
• The same behaviour occurs with ASAN_OPTIONS=symbolize=0, so the
  external symbolizer is not required to trigger the abort.
• No other processes are involved at that stage (no .ppo writing, no
  concurrent file access, static source tree).

I fully agree this is a deep dive, and I’m not expecting you to debug it
for me. I’m simply documenting the behaviour in case it helps identify a
platform‑specific UB hotspot triggered by clang/ARM64.

I’ll continue investigating on my side and will report back if I can
isolate a minimal C‑level reproducer or a specific code path.

[bertrandsoullier]

As a follow‑up, I also attempted to build a minimal C harness calling
hb_compMain() directly, linked against the installed static Harbour
libraries on Termux/ARM64 with ASan/UBSan enabled.

However, due to the way the runtime, VM, RDD, tracing and filesystem
layers are structured and linked (shared symbols across libhbvm,
libhbrtl, libhbnortl, and others), reproducing a standalone
“mini‑harbour” binary outside the official build system quickly turns
into re‑implementing Harbour’s own link logic. At that point the
exercise becomes significantly more complex than a simple harness.

Given this, the most reliable reproducer I currently have remains the
ASan/UBSan self‑build on Termux/ARM64, where the instrumented harbour
binary aborts while compiling harbinit.prg. If useful, I can provide
the exact build flags and a full build log.

I’ll continue investigating on my side and will report back if I can
isolate a smaller C‑level reproducer or a specific code path.