[meta-freescale] [meta-qt5] QtWebengine SIGBUS alignment exception

[Peter Fink]

Hi!

I made some progress investigating my problem, but still have some 
questions.

When I remove "thumb" from my TUNE_FEATURES qtwebengine runs without any 
issues.

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,
Peter


On 2018/03/12 at 08:55 Peter wrote:
> Hi!
>
> 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:
>
> [503:523:0309/095037.841842:ERROR:ssl_client_socket_impl.cc(1129)] 
> 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 
> http://heise.de/security
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> '/tmp/runtime-root'
> 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 
> QT_EGLFS_IMX6_NO_FB_MULTI_BUFFER=1
> [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 
> /usr/lib/libQt5WebEngineCore.so.5
> (gdb) backtrace
> #0  0x7349b5fc in _bsaes_key_convert () from 
> /usr/lib/libQt5WebEngineCore.so.5
> #1  0x7349b98e in bsaes_ctr32_encrypt_blocks () from 
> /usr/lib/libQt5WebEngineCore.so.5
> Backtrace stopped: previous frame identical to this frame (corrupt 
> stack?)
>
> 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,
> Peter