[meta-freescale] [meta-qt5] QtWebengine SIGBUS alignment exception
ub4_clb at yahoo.de
Wed Mar 14 02:11:32 PDT 2018
I made some progress investigating my problem, but still have some
When I remove "thumb" from my TUNE_FEATURES qtwebengine runs without any
Can somebody acknowledge this behavior? Just to be sure it's not an
issue of some other part of my setup.
#1) Why could this be an issue? Should we insert a warning or does
anybody have a clue on how I/we could possibly fix this?
Is it possible to override thumb/arm mode setting for a
single package in yocto?
#2) Which TUNE_FEATURES are recommended for i.mx6q/dl?
I based our distro on fslc-base/framebuffer and our board
on sabresd which uses "thumb".
#3) What advatages/disadvantages does the (not) using of thumb mode
cause for my whole system?
I already discovered, that e.g.
libQt5WebEngineCore.so.5.9.4 grew from ~50mb to ~120mb.
#4) Do I need -mcpu=cortex-a9 for i.mx6? Or is -march=armv7-a enough?
GCC doc state it is used to further optimize code for the
target. Is there a reason why is it not set for imx6q/dl on sabresd?
Thanks in advance,
On 2018/03/12 at 08:55 Peter wrote:
> Did anybody successfully run a qtwebengine application built with
> qt5.9 or 5.10 on rocko?
> I'm building for i.mx6 (eglfs) and getting more or less the same
> errors on 5.9 and 5.10.
> The problem seems to lie somewhere in
> qtwebengine/3rdparty/chromium/thirdparty/boringssl which makes it
> quite an easy target to debug...
> On 5.10 I get a bus errror (SIGBUS) because of an unaligned access:
> ./quicknanobrowser -platform eglfs http://heise.de/security
> Alignment trap: not handling instruction ecd6cb04 at [<734fd3b8>]
> Unhandled fault: alignment exception (0x001) at 0x734fcce1
> pgd = d9a70000
> [734fcce1] *pgd=69a75831, *pte=61c6359f, *ppte=61c63e7e
> Received signal 7 BUS_ADRALN 0000734fcce1
> #0 0x00007401b66a <unknown>
> #1 0x00007401b4e6 <unknown>
> #2 0x00007347ae48 <unknown>
> #3 0x00007401b8e2 <unknown>
> #4 0x00007635bbc0 <unknown>
> [end of stack trace]
> Calling _exit(1). Core file will not be generated.
> If I use https qtwebengine simply complains about the webpage not
> being available and throws the following error on the command line:
> handshake failed; returned -1, SSL error code 1, net_error -126
> So I traced the error down to bsaes_ctr32_encrypt_blocks inside the
> boringSSL implementation:
> Starting program: ./quicknanobrowser -platform eglfs
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
> QEglFSVivIntegration will set environment variable FB_MULTI_BUFFER=2
> to enable double buffering and vsync.
> If this is not desired, you can override this via: export
> [New Thread 0x681d53c0 (LWP 565)]
> Unable to query physical screen size, defaulting to 100 dpi.
> To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and
> QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
> qt.qpa.input: X-less xkbcommon not available, not performing key mapping
> [New Thread 0x673603c0 (LWP 566)]
> [New Thread 0x64a523c0 (LWP 567)]
> [New Thread 0x640ff3c0 (LWP 569)]
> [New Thread 0x638ff3c0 (LWP 570)]
> [New Thread 0x630ff3c0 (LWP 571)]
> [New Thread 0x628ff3c0 (LWP 572)]
> [New Thread 0x620ff3c0 (LWP 573)]
> [New Thread 0x618ff3c0 (LWP 574)]
> [New Thread 0x610ff3c0 (LWP 575)]
> [New Thread 0x608ff3c0 (LWP 576)]
> [New Thread 0x600ff3c0 (LWP 577)]
> [New Thread 0x5f8ff3c0 (LWP 578)]
> [New Thread 0x5f0ff3c0 (LWP 579)]
> [New Thread 0x5e8ff3c0 (LWP 580)]
> [New Thread 0x5e0ff3c0 (LWP 581)]
> [New Thread 0x5d8ff3c0 (LWP 582)]
> [New Thread 0x5d0ff3c0 (LWP 583)]
> [New Thread 0x5c8ff3c0 (LWP 584)]
> [New Thread 0x5c0ff3c0 (LWP 585)]
> [New Thread 0x5b8ff3c0 (LWP 586)]
> [New Thread 0x5b0ff3c0 (LWP 587)]
> [New Thread 0x5a81d3c0 (LWP 588)]
> [New Thread 0x597ff3c0 (LWP 597)]
> [Thread 0x597ff3c0 (LWP 597) exited]
> Alignment trap: not handling instruction ecd6cb04 at [<7349b5f8>]
> Unhandled fault: alignment exception (0x001) at 0x7349af21
> pgd = d8d50000
> [7349af21] *pgd=68a4e831, *pte=67c3059f, *ppte=67c30e7e
> Thread 19 "Chrome_IOThread" received signal SIGBUS, Bus error.
> [Switching to Thread 0x5d0ff3c0 (LWP 583)]
> 0x7349b5fc in _bsaes_key_convert () from
> (gdb) backtrace
> #0 0x7349b5fc in _bsaes_key_convert () from
> #1 0x7349b98e in bsaes_ctr32_encrypt_blocks () from
> Backtrace stopped: previous frame identical to this frame (corrupt
> I couldn't find an option to use system ssl libs instead of chromium's
> own libs or is there one hidden I'm not aware of?
> One possible problem I could imagine is boringssl being built for the
> wrong architecture, as there are multiple asm files for armv4, x86 and
> so on... do you think that's a likely cause or might my toolchain be
> broken somehow?
> Thanks in advance & best regards,
More information about the meta-freescale