[Qtwebengine] QT5.6.2 to 5.7.1 default behavior changes and qtWebengine ozone bridge

Michal Klocek michal.klocek at qt.io
Wed May 17 11:46:51 CEST 2017


Hi


Did you try different kernel ?

4.9 had recently some delete-after-use issue afaik

see https://patchwork.kernel.org/patch/9634773/

Br

Michal

On 05/17/2017 12:35 AM, Ruei, Eric via QtWebEngine wrote:
> Hi, Alex:
>
>
>
> Thanks for the information!
>
> With the help of strace, we found out that the FUTEX_UNLOCK_PI (0x07)
> was invoked once at the process with sandbox restriction as shown below:
>
>
>
> 3786  16:41:27.554470 futex(0xffffffff, FUTEX_UNLOCK_PI, 0) = -1093335620
>
>
>
> It seems to be a bad call with uaddr = -1, but I am more interested in
> finding which module invokes FUTEX_UNLOCK_PI.
>
> Is there a way to find out the originator of the futex system call in
> this scenario?
>
>
>
> Best regards,
>
>
>
> Eric
>
>
>
> *From:*Alexandru Croitor [mailto:alexandru.croitor at qt.io]
> *Sent:* Monday, May 15, 2017 3:45 AM
> *To:* Ruei, Eric
> *Cc:* qtwebengine at qt-project.org
> *Subject:* Re: [Qtwebengine] QT5.6.2 to 5.7.1 default behavior changes
> and qtWebengine ozone bridge
>
>
>
> Hi,
>
>
>
> I'm not sure how well supported is Qt Creator for embedded device, so I
> would advise to try setting the breakpoints from command line gdb, as
> well as checking if the symbols are actually found by GDB.
>
>
>
> WebEngine by default does not create / include debug symbols for Blink
> and V8, so if the call happens somewhere inside those components, the
> breakpoint will not be hit. Note that enabling those debug symbols will
> substantially increase link time as well RAM used. You can enable them
>
> by re-running qmake with something like
>
>
>
> qmake qt57_source/qtwebengine/qtwebengine.pro CONFIG+="webcore_debug
> v8base_debug"
>
> Those flags are in qtwebengine/src/core/gyp_run.pro
>
>
>
> Other debug symbols should in theory be there if you are doing a debug
> build.
>
>
>
>     On 12 May 2017, at 20:03, Ruei, Eric <e-ruei1 at ti.com
>     <mailto:e-ruei1 at ti.com>> wrote:
>
>
>
>     Hi, Alex:
>
>
>
>     Thank you very much for your invaluable help!
>
>     I have finally resumed to debug the qtwebengine seccomp issue after
>     a long break to other assignments.
>
>
>
>     Regarding the crash as shown below, it is caused by a restricted
>     FUTEX request (FUTEX_UNLOCK_PI)  at function  RestrictFutex()
>     @syscall_parameters_restrictions.cc
>
>
>
>     Render process exited with code 256 (abnormal exit)
>
>     /home/a0850410/yocto_builds/sdk400_am5/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/armv7ahf-neon-linux-gnueabi/qtwebengine/5.7.1+gitAUTOINC+9cc97f0c63_b3c79e92f0-r0.arago0/git/src/3rdparty/chromium/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:futex()
>     failure
>
>     Received signal 11 SEGV_MAPERR 000000000007
>
>     [end of stack trace]
>
>
>
>     I was trying to find out which module initiating the FUTEX call
>     (FUTEX_UNLOCK_PI) and there was no luck.
>
>     I could not set a breakpoint at  or within RestrictFutex(),
>      CrashSIGSYSFutex() and SIGSYSFutexFailure(), i.e. the breakpoints
>     do no work at QtCreator.
>
>     And the stack trace does not show anything. I wonder that I need to
>     set some build flag or option to enable chromium  debugging.
>
>
>
>     Any thoughts and inputs will be highly appreciated!
>
>
>
>     Best regards,
>
>
>
>     Eric
>
>
>
>     *From:* Alexandru Croitor [mailto:alexandru.croitor at qt.io]
>     *Sent:* Thursday, March 23, 2017 11:35 AM
>     *To:* Ruei, Eric
>     *Cc:* qtwebengine at qt-project.org <mailto:qtwebengine at qt-project.org>
>     *Subject:* Re: [Qtwebengine] QT5.6.2 to 5.7.1 default behavior
>     changes and qtWebengine ozone bridge
>
>
>
>     Hi,
>
>
>
>     I am not aware of the reason for the seccomp crash, but you can find
>     some similar reports with some info
>     at https://bugreports.qt.io/browse/QTBUG-57709 maybe that helps you
>     investigate the issue further.
>
>
>
>     Regarding GLES, I am not very familiar with that code, but it is
>     plausible it is incomplete. You could check if there are any code
>     changes in Qt 5.8.x and in unreleased Qt 5.9.0.
>
>
>
>     Rergards,
>
>     Alex.
>
>
>
>
>
>         On 23 Mar 2017, at 16:14, Ruei, Eric <e-ruei1 at ti.com
>         <mailto:e-ruei1 at ti.com>> wrote:
>
>
>
>         Hi, Alexandru:
>
>
>
>         Thank you so much!
>
>         The information that you provided is extremely helpful and it
>         may take me forever to get without your help!
>
>
>
>         For question #3, we are using Linux kernel 4.9.13 and
>         seccomp-bpf is enabled.
>
>         With the default setting, the following error occurs
>         continuously and the Seccomp is set to 0 at /proc/<pid>/status.
>
>
>
>         Render process exited with code 256 (abnormal exit)
>
>         /home/a0850410/yocto_builds/LTS2017_0/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/armv7ahf-neon-linux-gnueabi/qtwebengine/5.7.1+gitAUTOINC+9cc97f0c63_b3c79e92f0-r0/git/src/3rdparty/chromium/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:futex()
>         failure
>
>         Received signal 11 SEGV_MAPERR 000000000007
>
>         [end of stack trace]
>
>>
>
>
>         The qtwebengine demo browser works if seccomp-bpf sandbox is
>         disabled by --disable-seccomp-filter-sandbox.
>
>
>
>         Do you have any idea for question #4?
>
>
>
>         Best regards,
>
>
>
>         Eric
>
>
>
>
>
> _______________________________________________
> QtWebEngine mailing list
> QtWebEngine at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qtwebengine
>



More information about the QtWebEngine mailing list