An application works on your dev host but crashes on the ARM target — how do you debug?

Start by getting a useful crash report. If the application segfaults, enable core dumps on the target (ulimit -c unlimited, ensure /proc/sys/kernel/core_pattern points to a writable location). Copy the core dump and the unstripped binary (with debug symbols) to your host and analyze with arm-linux-gnueabihf-gdb binary core — the backtrace will show exactly where it crashed. If core dumps are not practical, run the application under gdbserver on the target and connect remotely from your host GDB.

The most common causes of host-works-target-crashes fall into a few categories. Endianness or alignment: if you cast pointers (e.g., uint32_t *p = (uint32_t *)byte_buffer), x86 tolerates unaligned access but ARM may not — Cortex-A will handle it with a performance penalty, but certain modes and older cores will fault. Toolchain mismatch: the target uses a different C library (musl vs glibc) or an older version with different behavior for edge cases. Memory constraints: the target has far less RAM — mmap or large allocations succeed on the host but fail on the target. Floating point: the binary was compiled for hard-float but the target uses soft-float, or vice versa.

Use sanitizers during cross-compilation: -fsanitize=address catches out-of-bounds accesses and use-after-free, -fsanitize=undefined catches undefined behavior like signed integer overflow and unaligned access. You can also use strace on the target to trace system calls and see where the application fails — this is often the fastest way to identify missing files, permission errors, or failed system calls. For memory issues specifically, valgrind works on ARM Linux targets (though it is slow) and catches leaks, invalid reads/writes, and uninitialized memory usage.