fix(webview): stop Pi 2/3 blank screen from gcc NEON alignment SIGBUS#3184
Open
vpetersson wants to merge 8 commits into
Open
fix(webview): stop Pi 2/3 blank screen from gcc NEON alignment SIGBUS#3184vpetersson wants to merge 8 commits into
vpetersson wants to merge 8 commits into
Conversation
The Qt5 WebEngine viewer crash-loops on the Pi 2 (and any armv7/Cortex-A
board), leaving a permanent blank screen: AnthiasViewer SIGBUSes on an
unaligned 64-bit NEON store (vst1 {q8},[rN:64]) that modern Debian gcc
(12-16) emits for struct zero-init/copy of 8-byte-aligned types via its
arm_block_set_aligned_vect block-move expander. Chromium/Qt hand some of
those pointers 4-byte-aligned addresses, so the :64 alignment assertion
faults on the Cortex-A7; the kernel can't fix up NEON, so it SIGBUSes.
gcc treats this as correct codegen (GCC PR 93031, WONTFIX); the previously
shipped toolchain only escaped it because it predated the Linaro->Debian
gcc switch.
Fix (both required):
- Append arm_use_neon=false to QtWebEngine's Chromium gn args (the fix
Yocto's meta-chromium / meta-lgsvl-browser ship) so general C++ compiles
-mfpu=vfpv3-d16; codec/graphics (libvpx, Skia) re-add NEON per-file with
runtime detection, preserving HW SIMD decode.
- Wrap the armhf cross gcc/g++ with -mno-unaligned-access so BOTH the
qmake-built Qt libs and Chromium's gn build lower the block move to
4-byte-safe vstr. arm_use_neon=false alone doesn't cover Qt's own libs.
Also makes the Qt5 toolchain rebuildable on Debian trixie (Python 3.13),
which dropped stdlib modules Chromium 87's build tooling still imports:
imp/pipes/cgi shims (src/anthias_webview/pyshim/) installed into python3
site-packages, a distro-six overwrite for grit's vendored six, and
python3-six/setuptools installs.
Validated on a real Pi 2: 0 alignment traps, stable viewer, renders
image/video/webpage, on the latest Qt 5.15.19 + Debian gcc-14.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates the Qt 5 WebView toolchain build to avoid ARMv7 (Pi 2/3) alignment SIGBUS crashes in QtWebEngine/Chromium builds with modern Debian GCC, and modernizes the legacy Chromium 87 build tooling for Debian trixie’s Python 3.13 removals.
Changes:
- Bump the pinned Qt5 toolchain release URL used by the image builder to
WebView-v2026.07.1. - Add Python 3.12/3.13 stdlib shims (
imp,pipes,cgi) to keep Chromium 87 tooling working on trixie. - Harden the Qt 5 toolchain build to avoid NEON-alignment faults by forcing
-mno-unaligned-accessvia compiler wrapping and settingarm_use_neon=falsein QtWebEngine’s Chromium GN args.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
| tools/image_builder/utils.py | Updates the pinned Qt5 toolchain release tag used during viewer image builds. |
| src/anthias_webview/pyshim/pipes.py | Provides pipes.quote compatibility via shlex.quote for Python 3.13+. |
| src/anthias_webview/pyshim/imp.py | Provides a minimal imp shim for Python 3.12+ to satisfy Chromium 87 build tooling imports. |
| src/anthias_webview/pyshim/cgi.py | Provides cgi.escape compatibility for Python 3.13+ to satisfy Chromium 87 build tooling imports. |
| src/anthias_webview/build_qt5.sh | Adds Python-compat setup and build-flag/toolchain wrapping to prevent ARMv7 alignment traps and keep the toolchain rebuildable on trixie. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The imp/pipes/cgi shims run only inside the Qt 5 toolchain builder image to satisfy Chromium 87's Python-2-era build tooling on trixie's Python 3.13; they emulate removed-stdlib APIs, so the app's strict typing and formatting rules don't apply. Same treatment as the sibling sysroot-relativelinks.py already gets. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… wrapper
Copilot review follow-ups on the Qt 5 toolchain build:
- Drop the `2>/dev/null || true` swallowing on the pyshim copy and the
six/setuptools installs — these are required on Python 3.13, so a real
failure should abort the build (set -e) instead of surfacing later as a
confusing ImportError inside a Chromium gn/ninja action.
- Make the -mno-unaligned-access compiler wrapper recursion-proof: move
the original aside to <tool>.real before writing the wrapper, so it can
never exec itself if arm-linux-gnueabihf-{gcc,g++} is a real binary
rather than an alternatives symlink.
- imp shim: correct the docstring (copied into site-packages, not
PYTHONPATH) and give NullImporter.find_module the optional legacy
`path` argument.
- cgi shim: document that escape() deliberately mirrors the stdlib
cgi.escape (double-quote only), not html.escape.
- utils: fix the stale WebView-v2026.07.0 comment (now 07.1).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- pyshim copy: guard on the glob matching real files so an empty/absent dir doesn't hand cp a literal `*.py` and abort under set -e. - -mno-unaligned-access wrapper: only wrap when the tool exists and isn't already wrapped (idempotent; doesn't pre-empt fetch_cross_compile_tool's own presence check). - arm_use_neon=false: grep-guard the common.pri append so a rebuild in the same workdir can't duplicate the line. - Bump the remaining WebView-v2026.07.0 references (docs, scripts, github release-filter test fixtures) to 07.1 for consistency with the pinned toolchain release. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Qt5 builder image installs python3 but not python3-pip, so the `|| pip3 install ...` fallback for six/setuptools could never actually run — if the apt install fails the pip3 call just errors with command-not-found. Install via apt only and let a real failure abort the build (set -e), which is the honest behaviour. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
find_module() computed a file handle from spec.origin unconditionally; for built-in/frozen modules origin is the sentinel 'built-in'/'frozen' (and None for namespace packages), so open() would fail. Only open a genuine file-backed origin. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The vendored-six overwrite swallowed all errors (2>/dev/null || true). six is installed earlier in the script so the import can't fail, and a silently-failed overwrite would only resurface later as the exact "No module named 'six.moves'" grit crash this step exists to prevent. Drop the swallowing and fold the two finds into one. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… handling Address Copilot review round 7 on the Python 3.13 `imp` shim: - find_module() now resolves built-in and frozen modules the way the historical stdlib imp did when called with no explicit path: check sys.builtin_module_names / FrozenImporter first (no import side effects) and return C_BUILTIN / PY_FROZEN with a None pathname instead of leaking importlib's 'built-in'/'frozen' sentinel through as a fake filename. PathFinder alone never surfaced these (they're on no path), so it previously raised ImportError for e.g. `sys`. - load_module() no longer assumes every PKG_DIRECTORY has an __init__.py: namespace packages (which find_module also classifies as PKG_DIRECTORY) now fall through to importlib.import_module instead of exec'ing a non-existent <dir>/__init__.py and raising. Verified against built-in (sys), frozen (_frozen_importlib), regular package (json), source module, and a synthetic namespace package. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Issues Fixed
Blank screen on Raspberry Pi 2 (forum report: https://forums.screenly.io/t/screen-stays-blank/6732). Same armv7 root cause underlies the intermittent
malloc(): unaligned tcachecrash tracked in issue 3022.Description
The Qt5 WebEngine viewer crash-loops on the Pi 2 (any armv7/Cortex-A board), leaving a permanent blank screen.
AnthiasViewerSIGBUSes on an unaligned 64-bit NEON store —vst1 {q8},[rN:64]— that modern Debian gcc (12–16, verified first-hand) emits for struct zero-init/copy of 8-byte-aligned types via itsarm_block_set_aligned_vectblock-move expander. Chromium/Qt hand some of those pointers 4-byte-aligned addresses, so the:64alignment assertion faults on the Cortex-A7; the ARM kernel can't fix up NEON, so SIGBUS → blank.gcc considers this correct codegen (GCC PR 93031, WONTFIX). The regression was the Linaro→Debian gcc toolchain switch (PR 3070), not the Qt 5.15.19 bump (PR 3121) — the old prebuilt toolchain only escaped it because it predated gcc-14. Bisecting Qt versions and newer gcc (13/14/15/16) does not help; this is the fix Yocto's Chromium recipes ship.
Fix (both parts required):
arm_use_neon=falseto QtWebEngine's Chromium gn args → general C++ compiles-mfpu=vfpv3-d16(no NEON block store); libvpx/Skia re-add NEON per-file with runtime detection, so HW SIMD video decode is preserved.gcc/g++with-mno-unaligned-accessso both the qmake-built Qt libs (libQt5Core/Gui/Qml/Quick) and Chromium's gn build lower the block move to 4-byte-safevstr.arm_use_neon=falsealone leaves Qt's own libs faulting.Also makes the Qt5 toolchain rebuildable on Debian trixie / Python 3.13 (a prerequisite):
imp/pipes/cgishims for stdlib modules Chromium 87's build tooling still imports, a distro-six overwrite for grit's broken vendored six, andpython3-six/setuptoolsinstalls.Validated on a real Pi 2: 0 alignment traps, stable viewer (no respawn loop), renders image/video/webpage, on the latest Qt 5.15.19 + Debian gcc-14. A weekend soak test across all asset types is running.
Required before merge (out-of-band, per the existing toolchain workflow): rebuild the pi2 + pi3 toolchain tarballs with this
build_qt5.shand upload them to a newWebView-v2026.07.1release (this PR pointsqt5_toolchain_urlthere). CI's pi2/pi3 viewer build will 404 until those artifacts exist. (pi2 built + validated; pi3 build in progress.)Checklist