@Nils-Sjoberg Thanks for the suggestion!
I tested with:
OPENSSL_armcap=0
Unfortunately, it doesn't change the behaviour. The application still crashes on the Raspberry Pi 3, so it doesn't appear to be an OpenSSL CPU capability detection issue.
However, I have an interesting update that may help narrow down the problem.
Originally, my WebEngineProfile was configured like this:
property string tmpDir: session.getPlatform() == "windows" ? "C:/Temp/xx" : "/tmp"
WebEngineProfile {
offTheRecord: false
persistentStoragePath: tmpDir + "/xx-webengine-" + content.uuid()
cachePath: tmpDir + "/xx-webcache-" + content.uuid()
}
So every WebEngineView was using a profile stored under /tmp, with a directory name based on content.uuid().
I then changed only the profile/cache location to a persistent directory under the user's home instead of /tmp, for example:
persistentStoragePath: "/home/xx/.local/share/xx/NeoPlayer/WebEngine/profile"
cachePath: "/home/xx/.local/share/xx/NeoPlayer/WebEngine/cache"
(or an equivalent persistent location).
Since this change:
the application progresses much further during startup,
several crashes no longer occur,
the remaining crash is now consistently inside QtWebEngineCore, typically in a thread named CacheThread_Blo, with a backtrace ending in malloc() / operator new() inside libQt5WebEngineCore.so.
In other words, changing only persistentStoragePath and cachePath significantly changes the failure mode.
What puzzles me is that the original code works perfectly on a Raspberry Pi 5, while it crashes on the Raspberry Pi 3.
Some additional comparison between the two systems:
Both run Debian 13 (Trixie).
/tmp is a tmpfs on both systems.
Both use the same application source code.
Both are built from the same Qt 5.15.17 build system (with architecture-specific binaries).
The Raspberry Pi 5 runs AArch64 (64-bit), while the Raspberry Pi 3 runs ARMv7 (32-bit).
This makes me wonder whether the issue is not /tmp itself, but rather how QtWebEngine/Chromium initializes and manages a WebEngineProfile on 32-bit ARM. Changing the profile location seems to alter the internal initialization sequence enough that the crash either disappears or occurs much later during startup.
Am I overlooking something about how WebEngineProfile is expected to be used? In particular:
Is storing a WebEngineProfile under /tmp considered bad practice or unsupported?
Is creating profile directories dynamically using content.uuid() likely to expose issues or race conditions inside QtWebEngine?
Would you instead recommend creating a single long-lived WebEngineProfile and reusing it across all WebEngineView instances?
Has anyone seen similar behaviour where changing only persistentStoragePath or cachePath changes or eliminates crashes in QtWebEngine?
If there are other diagnostics that would help identify the root cause, I'd be happy to run them and share the results.
