Alt+F4 crashes app where WebView embedded in a Window

[Atbeyi]

was just watching something on Youtube Web App created by unity itself. when i pressed alt-f4 Ubuntu said it had an error and if i want to submit it.

that is all folks.

ProblemType: Crash
DistroRelease: Ubuntu 15.04
Package: webapp-container 0.23+15.04.20150320.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1
Uname: Linux 3.19.0-9-generic x86_64
ApportVersion: 2.16.2-0ubuntu4
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Mar 23 19:56:16 2015
Disassembly: => 0x0: Cannot access memory at address 0x0
ExecutablePath: /usr/bin/webapp-container
InstallationDate: Installed on 2015-03-22 (0 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Alpha amd64 (20150306)
ProcCmdline: webapp-container --app-id=YouTubeyoutubecom --webapp=WW91VHViZQ== --enable-back-forward
SegvAnalysis:
 Segfault happened at: 0x0: Cannot access memory at address 0x0
 PC (0x00000000) not located in a known VMA region (needed executable region)!
SegvReason: executing NULL VMA
Signal: 11
SourcePackage: webbrowser-app
StacktraceTop:
 ?? ()
 ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so
 QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
 ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so
 ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so
Title: webapp-container crashed with SIGSEGV in QMetaObject::activate()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

[Apport retracing service (apport)]

StacktraceTop:
 ?? ()
 QIBusPlatformInputContext::updatePreeditText (this=0x7fbde0762090, text=..., cursorPos=0, visible=<optimized out>) at qibusplatforminputcontext.cpp:232
 QMetaObject::activate (sender=0x7fbde0781400, signalOffset=<optimized out>, local_signal_index=local_signal_index@entry=19, argv=argv@entry=0x7ffc1f1f1ce0) at kernel/qobject.cpp:3716
 QMetaObject::activate (sender=<optimized out>, m=m@entry=0x7fbdd008cd00 <QIBusInputContextProxy::staticMetaObject>, local_signal_index=local_signal_index@entry=19, argv=argv@entry=0x7ffc1f1f1ce0) at kernel/qobject.cpp:3582
 QIBusInputContextProxy::UpdatePreeditText (this=<optimized out>, _t1=..., _t2=0, _t3=false) at .moc/moc_qibusinputcontextproxy.cpp:613

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Olivier Tilloy (osomon)]

I can reliably reproduce the crash on my desktop running xenial. It affects both webbrowser-app and webapp-container. I’m getting a similar backtrace when pressing Alt+F4 while browsing youtube.com.
I’m getting a different backtrace when browsing other sites:

(gdb) bt
#0 0x00007ffff6500dc2 in typeinfo name for QSocketNotifierPrivate () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Backtrace stopped: Cannot access memory at address 0x0

In all cases, Alt+F4 crashes the app.

[Olivier Tilloy (osomon)]

Could be related to bug #1448079.

[Olivier Tilloy (osomon)]

Crash is still happening even with the latest changes to the shutdown sequence in oxide trunk.

I’ve observed that closing a window by sending it a _NET_CLOSE_WINDOW message (using e.g. wmctrl -c) doesn’t trigger the crash, so it’s really only the Alt+F4 keyboard shortcut that causes the issue.

[Olivier Tilloy (osomon)]

I can reliably reproduce the crash with the following minimal QML scene (run in qmlscene):

import QtQuick 2.4
import QtQuick.Window 2.2
import com.canonical.Oxide 1.15
Window {
  width: 400
  height: 300
  WebView {
    anchors.fill: parent
    url: "http://example.org"
  }
}

[Olivier Tilloy (osomon)]

The difference between having the root item of the scene being a plain Item or a Window is that I’m seeing the destructor for BrowserThreadQEventDispatcher being called (Item) or not (Window).

When the root item of the scene is not a Window, qmlscene wraps the scene in a QQuickView, which inherits from QQuickWindow.

[Olivier Tilloy (osomon)]

ShutdownChromium() is not being called when the root item of the scene is a QQuickWindow.

[Olivier Tilloy (osomon)]

When the app under test has multiple top-level windows (each embedding webviews), closing only one of them with Alt+F4 also results in a crash, although clearly in that case the application is not being torn down (and chromium is not being shut down).

In that case, the crash looks different (although I’m still not getting a proper backtrace):

Thread 1 "webbrowser-app" received signal SIGSEGV, Segmentation fault.
0x00007ffff6496d3f in qt_meta_data_QSingleShotTimer () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

[Chris Coulson (chrisccoulson)]

Running it in valgrind gives a clue:

==19941== Invalid read of size 4
==19941== at 0x6604DA4: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==19941== by 0x1877174F: ???
==19941== by 0xFFFFFFFFFFFFFFFD: ???
==19941== by 0x2483D3FE: ??? (in /usr/lib/x86_64-linux-gnu/libOxideQtCore.so.0)
==19941== by 0x27C117AB: ??? (in /usr/lib/x86_64-linux-gnu/libOxideQtCore.so.0)
==19941== by 0x27C36ADC: ??? (in /usr/lib/x86_64-linux-gnu/libOxideQtCore.so.0)
==19941== by 0x27C3DDD3: ??? (in /usr/lib/x86_64-linux-gnu/libOxideQtCore.so.0)
==19941== by 0x27C3E1A8: ??? (in /usr/lib/x86_64-linux-gnu/libOxideQtCore.so.0)
==19941== by 0x24861F42: ??? (in /usr/lib/x86_64-linux-gnu/libOxideQtCore.so.0)
==19941== by 0x24861FF8: ??? (in /usr/lib/x86_64-linux-gnu/libOxideQtCore.so.0)
==19941== by 0x2414E312: QScopedPointerDeleter<oxide::qt::WebViewProxy>::cleanup(oxide::qt::WebViewProxy*) (in /usr/lib/x86_64-linux-gnu/libOxideQtQuick.so.0)
==19941== by 0x2414D996: QScopedPointer<oxide::qt::WebViewProxy, QScopedPointerDeleter<oxide::qt::WebViewProxy> >::~QScopedPointer() (in /usr/lib/x86_64-linux-gnu/libOxideQtQuick.so.0)
==19941== by 0x241467FB: OxideQQuickWebViewPrivate::~OxideQQuickWebViewPrivate() (in /usr/lib/x86_64-linux-gnu/libOxideQtQuick.so.0)
==19941== by 0x24146847: OxideQQuickWebViewPrivate::~OxideQQuickWebViewPrivate() (in /usr/lib/x86_64-linux-gnu/libOxideQtQuick.so.0)
==19941== by 0x2414E4D6: QScopedPointerDeleter<OxideQQuickWebViewPrivate>::cleanup(OxideQQuickWebViewPrivate*) (in /usr/lib/x86_64-linux-gnu/libOxideQtQuick.so.0)
==19941== by 0x2414DED6: QScopedPointer<OxideQQuickWebViewPrivate, QScopedPointerDeleter<OxideQQuickWebViewPrivate> >::~QScopedPointer() (in /usr/lib/x86_64-linux-gnu/libOxideQtQuick.so.0)
==19941== by 0x24147E1C: OxideQQuickWebView::~OxideQQuickWebView() (in /usr/lib/x86_64-linux-gnu/libOxideQtQuick.so.0)
==19941== by 0x240855BD: QQmlPrivate::QQmlElement<OxideQQuickWebView>::~QQmlElement() (in /usr/lib/x86_64-linux-gnu/qt5/qml/com/canonical/Oxide/libqmloxideplugin.so)
==19941== by 0x240855F3: QQmlPrivate::QQmlElement<OxideQQuickWebView>::~QQmlElement() (in /usr/lib/x86_64-linux-gnu/qt5/qml/com/canonical/Oxide/libqmloxideplugin.so)
==19941== by 0x64BE52A: QObjectPrivate::deleteChildren() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==19941== by 0x64C7D9F: QObject::~QObject() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==19941== by 0x5DBD028: QWindow::~QWindow() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1)
==19941== by 0x4FD26E8: QQuickWindow::~QQuickWindow() (in /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.5.1)
==19941== by 0x50AA74C: QQmlPrivate::QQmlElement<QQuickWindowQmlImpl>::~QQmlElement() (in /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.5.1)
==19941== by 0x405115: main (in /usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene)
==19941== Address 0x151bcd9e is 18 bytes before a block of size 664 alloc'd
==19941== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19941== by 0x50A96E9: QQuickWindowQmlImpl::QQuickWindowQmlImpl(QWindow*) (in /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.5.1)
...

[Olivier Tilloy (osomon)]

Might be https://bugreports.qt.io/browse/QTBUG-46414.

[Olivier Tilloy (osomon)]

I can confirm that https://codereview.qt-project.org/#/c/108517/ fixes the crash.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Timo Jyrinki (timo-jyrinki)]

The full story is that after the commit it was reverted in 5.6 https://codereview.qt-project.org/#/c/147886/ with a comment "It's too risky for 5.6, we should let it cook in dev for a while
and backport when ready.", but then also that revert got merged to dev so as far as I can see upstream does not have any fix for the bug :(

I asked in the bug report two days ago whether there's going to be some activity on it, and then in addition to dev it'd be nice to have some non-risky 5.6 variant of it.

[Simon Quigley (tsimonq2)]

Seems like this is fixed now.