SIGBUS BUS_ADRALN on an Android signage player: what the fault means

What signal 7 and BUS_ADRALN mean

Linux fixes the signal numbers, and Android keeps the same table. Signal 7 is SIGBUS: the kernel stopped the process over a bad memory access at the bus level, and the code number after it names the kind. Code 1 is BUS_ADRALN, an alignment fault: the instruction asked for a value at an address that misses that value's boundary. On a 32-bit Arm build, the pointer and reference-count operations in the media stack are 4-byte reads that want a 4-byte aligned address, so an odd address kills the process. On a 64-bit build the same code typically runs clean, because Arm64 handles unaligned access to ordinary memory in hardware, which is why this fault hides until the app meets a 32-bit box.

Android's native fault handler prints the signal, the code, the fault address, the registers and the backtrace, and drops a tombstone file with the same detail. A Java exception, like the out of memory failure after hours we cover separately, prints a stack trace from the app; a SIGBUS line comes from the kernel. When an app stops, our player is designed to start again within seconds and go back to the show.

How to read the fault line

A typical line looks like this:

F libc : Fatal signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x6e676977 in tid 1159 (RenderThread), pid 1060

Read it in order. Signal 7 with code 1 (BUS_ADRALN) says native and unaligned. fault addr is the address that was touched. tid and the name in brackets are the thread that died: RenderThread is the thread that draws and moves the picture surfaces. pid is the process. The tombstone header repeats the fields that settle the rest:

ABI: 'arm'

>>> com.signage.twfidrxfsw <<<

uid: 10023

ABI: 'arm' means a 32-bit build; on Android 11 that is the build class where this fault shows. The name between the >>> marks is the process that died, and that one field settles the argument about what failed: if it is your player's package, the fault belongs to the app.

What each part of the log points to

• SIGBUS, code 1 (BUS_ADRALN): a native alignment fault in that process. The software is the suspect.
• Thread name RenderThread: the fault fired while the system prepared and moved picture surfaces.
• Backtrace frames SurfaceControl.Transaction.reparent and the positionLost callback on the SurfaceView: the video window was being moved or removed when the fault fired. A player draws video through a SurfaceView, so a slide change that resizes it and a video ending both walk this path.
• Top frame in libutils.so at android::RefBase::incStrong+4: a reference count increment on a bad pointer, the signature of a stale surface handle.
• Every other frame sits in system libraries, libandroid_runtime.so, libhwui.so, libart.so, libc.so. The app's contribution was handing over a surface handle that no longer pointed at a live object.
• After the fault, logd, init and BootReceiver keep logging and ActivityManager prints that the process has died: one app died, the box did not.
• A power problem looks different: the whole log stops and the box boots from scratch. A black picture with a live log is another problem again, the one our article on a black screen on video covers.

Checks before you change hardware

1. Read the crash buffer. Fault lines sit in their own log buffer; on a box that exposes ADB, adb logcat -b crash prints just that.
2. Confirm the dying process. The name between the >>> marks must be your player's package. If a system process dies there, the box firmware is the suspect and the app vendor is the wrong addressee.
3. Confirm the repeat. The same signal, the same top frames and a fresh timestamp mean a deterministic code path, not a one-off.
4. Rule power out with the log first. If logd, init and BootReceiver keep logging after the app dies, the box never blinked. A box that reboots needs power work before anything else: our guide on wiring 12 to 36 V DC power covers the checks, and our article on signage power loss recovery explains what a player should do after the power returns.
5. Collect the record: the tombstone under /data/tombstones, the example box wrote tombstone_02, plus the SYSTEM_TOMBSTONE copy the system files in DropBox.
6. Write down the versions: app build, Android version, ABI. In the example that is a 2.217-series app build on Android 11, ABI arm.

Example: one fault report, start to decision

Scenario: a signage box on Android 11 stops while the playlist changes over, and the log shows the line above.

At 12:27:31.635, tid 1159 (RenderThread) of pid 1060 took signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x6e676977.

Decode the fault address. An Arm box stores the lowest byte first, so 0x6e676977 splits into bytes 77, 69, 67, 6e. In decimal that is 119, 105, 103, 110, which in ASCII spells w, i, g, n. Register r0 held 0x6e676973: bytes 73, 69, 67, 6e, decimal 115, 105, 103, 110, spelling s, i, g, n. The pointer that crashed was string text. Addresses handed out by the memory manager never spell words, so a value from a text buffer got loaded as a pointer, and that is a software fault in the app's native code.

Identify the victim. The tombstone reads >>> com.signage.twfidrxfsw <<< with uid 10023, an ordinary app identity, and the package is the player.

Read the backtrace. Frame #00 is android::RefBase::incStrong+4 in libutils.so, a 4-byte reference count increment. Frame #01 is android::nativeReparent+50 in libandroid_runtime.so. Frame #03 is SurfaceControl.Transaction.reparent and frame #05 is the positionLost callback on the SurfaceView: the render thread was moving or removing the video surface and hit the bad pointer while bumping a reference count.

Check the box survived. At 12:27:33.765 BootReceiver copied /data/tombstones/tombstone_02, and at 12:27:33.971 ActivityManager recorded the process has died. Fault to teardown is about 2.3 seconds, and every other service kept logging through it.

Decision: a player app bug on a 32-bit Android 11 arm build, triggered on the video surface teardown path. Install a newer app build and send the vendor the tombstone.

The fix

Update the player app on that box. An alignment fault lives in compiled code; no resolution, orientation or power setting reaches the instruction that made the unaligned read. If the vendor has published a newer build, install it and watch one full loop of the playlist. If there is no newer build yet, roll the box back to the last build that ran clean and keep its installer.

Send the vendor the tombstone and the fault line: signal 7, code 1 (BUS_ADRALN), the fault address, the ABI and the backtrace give a developer the complete fault description. If the app offers a setting for how it draws video, a native surface against a drawn texture, switching it moves the fault off the reparent path while you wait; treat that as a workaround, because the bad pointer is still in the build.

Both ways of running the box are legitimate: a player set as the home app, or a player running as a normal app beside the vendor's launcher when the box's own services have to stay alive. Neither one causes an alignment fault. The startup choices are covered in our article on Android signage app startup for a single-purpose display. The same log reading applies to any Android player box, including the Android all-in-one displays we build: the codes never change meaning between boxes, and our own player is designed to start again within seconds when an app stops and go back to the show.

Recommendation: treat SIGBUS with code 1 (BUS_ADRALN) as an app bug whenever the >>> name is your player's package and the fault repeats at the same frames. Update the app on that box first, keep the last clean build for rollback, and leave the screen, cable and power wiring alone unless the log shows the whole box going down. Send the app vendor the tombstone; it carries the signal, code, fault address, ABI and backtrace they need.

Questions