Bug #1421009 “unity8 sometimes hangs on boot” : Bugs : Canonical System Image

Revision history for this message

Michael Terry (mterry) wrote on 2015-02-12:

#1

Download full text (15.5 KiB)

I just got this after 7 tries. On the screen is the Ubuntu spinner. Here's a stacktrace:

(gdb) bt full
#0 0xffffffff in syscall () at /lib/arm-linux-gnueabihf/libc.so.6
#1 0xffffffff in QBasicMutex::lockInternal() (op=0, val=3, timeout=0x0, addr=<optimized out>) at thread/qmutex_linux.cpp:154
        addr2 = 0x0
        val2 = 0
#2 0xffffffff in QBasicMutex::lockInternal() (timeout=-1, elapsedTimer=0x0, d_ptr=...) at thread/qmutex_linux.cpp:195
#3 0xffffffff in QBasicMutex::lockInternal() (this=this@entry=0x132b2e4)
    at thread/qmutex_linux.cpp:211
#4 0xffffffff in QMutex::lock() (this=0x132b2e4) at thread/qmutex.h:67
        self = 0xb6efd410
        success = true
        current = 0x132b2d8
#5 0xffffffff in QMutex::lock() (timeout=-1, this=0x132b2d8)
    at thread/qmutex.cpp:628
        self = 0xb6efd410
        success = true
        current = 0x132b2d8
#6 0xffffffff in QMutex::lock() (this=this@entry=0x132b414)
    at thread/qmutex.cpp:223
        current = 0x132b2d8
#7 0xffffffff in qDBusRealToggleWatch(QDBusConnectionPrivate*, DBusWatch*, int) (m=0x132b414, s=0x132b3f0, a=ToggleWatchAction, this=<synthetic pointer>)
    at qdbusthreaddebug_p.h:191
        locker =
            {<QDBusMutexLocker> = {<QDBusLockerBase> = {<No data fields>}, self = 0x132b3f0, mutex = 0x132b414, action = ToggleWatchAction}, <No data fields>}
        i = <optimized out>
#8 0xffffffff in qDBusRealToggleWatch(QDBusConnectionPrivate*, DBusWatch*, int) (s=0x132b3f0, a=ToggleWatchAction, this=<synthetic pointer>)
    at qdbusthreaddebug_p.h:206
        locker =
            {<QDBusMutexLocker> = {<QDBusLockerBase> = {<No data fields>}, self = 0x132b3f0, mutex = 0x132b414, action = ToggleWatchAction}, <No data fields>}
        i = <optimized out>
#9 0xffffffff in qDBusRealToggleWatch(QDBusConnectionPrivate*, DBusWatch*, int) (d=0x132b3f0, watch=0x132c480, fd=41) at qdbusintegrator.cpp:344
        locker =
            {<QDBusMutexLocker> = {<QDBusLockerBase> = {<No data fields>}, self = 0x132b3f0, mutex = 0x132b414, action = ToggleWatchAction}, <No data fields>}
        i = <optimized out>
#10 0xffffffff in check_write_watch (transport=0x132c3e8)
    at ../../dbus/dbus-transport-socket.c:167
        needed = <optimized out>
        transport = 0x132c3e8
        socket_transport = 0x132c3e8
#11 0xffffffff in socket_do_iteration (transport=0x132c3e8, flags=1, timeout_milliseconds=<optimized out>) at ../../dbus/dbus-transport-socket.c:1210
        socket_transport = 0x132c3e8
        poll_fd = {fd = 41, events = 0, revents = -16705}
        poll_res = <optimized out>
        poll_timeout = <optimized out>
#12 0xffffffff in _dbus_transport_do_iteration (transport=0x132c3e8, flags=1, timeout_milliseconds=-1) at ../../dbus/dbus-transport.c:1001
#13 0xffffffff in _dbus_connection_do_iteration_unlocked (connection=0x132c808, pending=<optimized out>, flags=1, timeout_milliseconds=-1)
    at ../../dbus/dbus-connection.c:1227
#14 0xffffffff in _dbus_connection_send_preallocated_unlocked_no_update (connection=connection@entry=0x132c808, preallocated=0x0, message=message@entry=0x14ee998, client_serial=client_serial@entry=0x0) at ../../dbus/dbus-connection.c:205...

I just got this after 7 tries.  On the screen is the Ubuntu spinner.  Here's a stacktrace:

(gdb) bt full
#0  0xffffffff in syscall () at /lib/arm-linux-gnueabihf/libc.so.6
#1  0xffffffff in QBasicMutex::lockInternal() (op=0, val=3, timeout=0x0, addr=<optimized out>) at thread/qmutex_linux.cpp:154
        addr2 = 0x0
        val2 = 0
#2  0xffffffff in QBasicMutex::lockInternal() (timeout=-1, elapsedTimer=0x0, d_ptr=...) at thread/qmutex_linux.cpp:195
#3  0xffffffff in QBasicMutex::lockInternal() (this=this@entry=0x132b2e4)
    at thread/qmutex_linux.cpp:211
#4  0xffffffff in QMutex::lock() (this=0x132b2e4) at thread/qmutex.h:67
        self = 0xb6efd410
        success = true
        current = 0x132b2d8
#5  0xffffffff in QMutex::lock() (timeout=-1, this=0x132b2d8)
    at thread/qmutex.cpp:628
        self = 0xb6efd410
        success = true
        current = 0x132b2d8
#6  0xffffffff in QMutex::lock() (this=this@entry=0x132b414)
    at thread/qmutex.cpp:223
        current = 0x132b2d8
#7  0xffffffff in qDBusRealToggleWatch(QDBusConnectionPrivate*, DBusWatch*, int) (m=0x132b414, s=0x132b3f0, a=ToggleWatchAction, this=<synthetic pointer>)
    at qdbusthreaddebug_p.h:191
        locker = 
            {<QDBusMutexLocker> = {<QDBusLockerBase> = {<No data fields>}, self = 0x132b3f0, mutex = 0x132b414, action = ToggleWatchAction}, <No data fields>}
        i = <optimized out>
#8  0xffffffff in qDBusRealToggleWatch(QDBusConnectionPrivate*, DBusWatch*, int) (s=0x132b3f0, a=ToggleWatchAction, this=<synthetic pointer>)
    at qdbusthreaddebug_p.h:206
        locker = 
            {<QDBusMutexLocker> = {<QDBusLockerBase> = {<No data fields>}, self = 0x132b3f0, mutex = 0x132b414, action = ToggleWatchAction}, <No data fields>}
        i = <optimized out>
#9  0xffffffff in qDBusRealToggleWatch(QDBusConnectionPrivate*, DBusWatch*, int) (d=0x132b3f0, watch=0x132c480, fd=41) at qdbusintegrator.cpp:344
        locker = 
            {<QDBusMutexLocker> = {<QDBusLockerBase> = {<No data fields>}, self = 0x132b3f0, mutex = 0x132b414, action = ToggleWatchAction}, <No data fields>}
        i = <optimized out>
#10 0xffffffff in check_write_watch (transport=0x132c3e8)
    at ../../dbus/dbus-transport-socket.c:167
        needed = <optimized out>
        transport = 0x132c3e8
        socket_transport = 0x132c3e8
#11 0xffffffff in socket_do_iteration (transport=0x132c3e8, flags=1, timeout_milliseconds=<optimized out>) at ../../dbus/dbus-transport-socket.c:1210
        socket_transport = 0x132c3e8
        poll_fd = {fd = 41, events = 0, revents = -16705}
        poll_res = <optimized out>
        poll_timeout = <optimized out>
#12 0xffffffff in _dbus_transport_do_iteration (transport=0x132c3e8, flags=1, timeout_milliseconds=-1) at ../../dbus/dbus-transport.c:1001
#13 0xffffffff in _dbus_connection_do_iteration_unlocked (connection=0x132c808, pending=<optimized out>, flags=1, timeout_milliseconds=-1)
    at ../../dbus/dbus-connection.c:1227
#14 0xffffffff in _dbus_connection_send_preallocated_unlocked_no_update (connection=connection@entry=0x132c808, preallocated=0x0, message=message@entry=0x14ee998, client_serial=client_serial@entry=0x0) at ../../dbus/dbus-connection.c:2057
#15 0xffffffff in _dbus_connection_send_and_unlock (client_serial=0x0, message=0x14ee998, preallocated=<optimized out>, connection=0x132c808)
    at ../../dbus/dbus-connection.c:2077
        status = <optimized out>
        preallocated = <optimized out>
#16 0xffffffff in _dbus_connection_send_and_unlock (connection=0x132c808, message=0x14ee998, client_serial=0x0) at ../../dbus/dbus-connection.c:2114
        preallocated = <optimized out>
#17 0xffffffff in dbus_bus_add_match (connection=0x132c808, rule=0x1816360 "type='signal',sender='com.canonical.UserMetrics',path='/com/canonical/UserMetrics/DataSource/3',interface='com.canonical.usermetrics.DataSource',member='emptyDataStringChanged'", error=0x0) at ../../dbus/dbus-bus.c:1553
        msg = 0x14ee998
        __FUNCTION__ = "dbus_bus_add_match"
#18 0xffffffff in QDBusConnectionPrivate::connectSignal(QString const&, QDBusConnectionPrivate::SignalHook const&) (error=0x0, rule=<optimized out>, connection=<optimized out>) at qdbus_symbols_p.h:90
        it = <optimized out>
        __PRETTY_FUNCTION__ = "void QDBusConnectionPrivate::connectSignal(const QString&, const QDBusConnectionPrivate::SignalHook&)"
#19 0xffffffff in QDBusConnectionPrivate::connectSignal(QString const&, QDBusConnectionPrivate::SignalHook const&) (this=this@entry=0x132b3f0, key=..., hook=...) at qdbusintegrator.cpp:2180
        it = <optimized out>
        __PRETTY_FUNCTION__ = "void QDBusConnectionPrivate::connectSignal(const QString&, const QDBusConnectionPrivate::SignalHook&)"
#20 0xffffffff in QDBusConnectionPrivate::connectRelay(QString const&, QString const&, QString const&, QDBusAbstractInterface*, QMetaMethod const&) (this=0x132b3f0, service=..., path=..., interface=..., receiver=receiver@entry=0x1814670, signal=...) at qdbusintegrator.cpp:2351
        key = {static null = {<No data fields>}, d = 0x18164a0}
        sig = {d = 0x1816230}
        locker = 
          {<QDBusLockerBase> = {<No data fields>}, self = 0x132b3f0, action = ConnectRelayAction}
        end = {i = 0x132e588}
        hook = 
            {service = {static null = {<No data fields>}, d = 0x1815880}, path = {static null = {<No data fields>}, d = 0x161b748}, signature = {static null = {<No data fields>}, d = 0x1816300}, obj = 0x1814670, midx = 6, params = {d = 0x1815fd0}, argumentMatch = {<QList<QString>> = {{p = {static shared_null = {ref = {atomic = {_q_value = -1}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0xb64bca90 <QListData::shared_null>}, d = 0xb64bca90 <QListData::shared_null>}}, <No data fields>}, matchRule = {d = 0x1816350}}
        it = {i = 0xaeb166d8}
#21 0xffffffff in QDBusAbstractInterface::connectNotify(QMetaMethod const&) (this=0x1814670, signal=...) at qdbusabstractinterface.cpp:612
        destroyedSignal = 
          {mobj = 0x29278 <QObject::staticMetaObject>, handle = 14}
#22 0xffffffff in QMetaObjectPrivate::connect(QObject const*, int, QMetaObject const*, QObject const*, int, QMetaObject const*, int, int*) (sender=0x1814670, signal_index=3, smeta=0xa88e4cf0 <ComCanonicalUsermetricsDataSourceInterface::staticMetaObject>, receiver=<optimized out>, method_index=6, rmeta=0xa88e4540 <UserMetricsOutput::DataSource::staticMetaObject>, type=0, types=0x0)
    at kernel/qobject.cpp:3259
        s = 0x1814670
        callFunction = 0xa88c8509 <UserMetricsOutput::DataSource::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>
        locker = 
          {mtx1 = 0xb65fea70 <_q_ObjectMutexPool+324>, mtx2 = 0xb65feaf0 <_q_ObjectMutexPool+452>, locked = false}
        c = {d = 0x18162a8}
        r = <optimized out>
        smethod = 
          {mobj = 0xa88e4cf0 <ComCanonicalUsermetricsDataSourceInterface::staticMetaObject>, handle = 14}
#23 0xffffffff in QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) (sender=0x1814670, signal=<optimized out>, receiver=receiver@entry=0x1815a68, method=<optimized out>, type=type@entry=Qt::AutoConnection) at kernel/qobject.cpp:2713
        __PRETTY_FUNCTION__ = "static QMetaObject::Connection QObject::connect(const QObject*, const char*, const QObject*, const char*, Qt::ConnectionType)"
        signalTypes = 
            {a = 10, s = 1, ptr = 0xbebfe2a8, {array = "\n\000\000\000\030Y\201\001X㿾\330[\201\001H\264\062\001\350t\030\266\004\000\000\000\022\000\000\000\001\000\000\000\002\000\000\000\020\177\360\266hZ\201\001\235n\214\250#1\017\266\000\000\000\000\000\000\000\000\020\000\000\000\004\000\000\000\000\000\000\000\351L.\266", q_for_alignment_1 = 108465825647689738, q_for_alignment_2 = 2.0237847769712101e-301}}
        tmp_method_name = {d = 0x18150f0}
        method_arg = <optimized out>
        methodName = {d = 0x1815f78}
        types = 0x0
        handle = {d_ptr = 0x0}
        tmp_signal_name = {d = 0x1815f90}
        rmeta = 0xa88e4540 <UserMetricsOutput::DataSource::staticMetaObject>
        method_index_relative = 6
        smeta = 0xa88e4cf0 <ComCanonicalUsermetricsDataSourceInterface::staticMetaObject>
        signal_arg = <optimized out>
        signalName = {d = 0x1815f60}
        signal_index = 3
        methodTypes = 
            {a = 10, s = 1, ptr = 0xbebfe308, {array = "\n\000\000\000p\353\200\001\000\320_\266L\017\215\250\000\000\000\000\333LH\266\000`&\266X㿾\001\000\000\000X㿾\020\177\360\266H(~\001L\017\215\250\020\177\360\266\020\177\360\266hZ\201\001\235n\214\250Ǳ3\266H_\201\001\063\262\063\266", q_for_alignment_1 = 108345257325756426, q_for_alignment_2 = 1.9738149582863987e-301}}
#24 0xffffffff in UserMetricsOutput::SyncedDataSource::SyncedDataSource(QSharedPointer<ComCanonicalUsermetricsDataSourceInterface>, QString const&, QObject*) (this=0x1815a68, interface=..., localeDir=..., parent=<optimized out>)
    at /build/buildd/libusermetrics-1.1.1+14.10.20141020/src/libusermetricsoutput/SyncedDataSource.cpp:31
#25 0xffffffff in UserMetricsOutput::SyncedUserMetricsStore::addDataSource(QDBusObjectPath const&) (this=this@entry=0x17e2830, path=...)
    at /build/buildd/libusermetrics-1.1.1+14.10.20141020/src/libusermetricsoutput/SyncedUserMetricsStore.cpp:137
        dataSource = {value = <optimized out>, d = 0x1814758}
#26 0xffffffff in UserMetricsOutput::SyncedUserMetricsStore::sync() (this=0x17e2830)
    at /build/buildd/libusermetrics-1.1.1+14.10.20141020/src/libusermetricsoutput/SyncedUserMetricsStore.cpp:66
        path = <optimized out>
        __for_range = <unknown type in /usr/lib/debug/.build-id/fb/f5574326e5704e94ee764c36b1b503f847631c.debug, CU 0x103906, DIE 0x13df05>
        interface = <optimized out>
        systemData = <optimized out>
#27 0xffffffff in QObject::event(QEvent*) (this=<optimized out>, e=<optimized out>) at kernel/qobject.cpp:1241
        mce = <optimized out>
        sw = 
          {receiver = 0x17e2830, previousSender = 0x0, currentSender = {sender = 0x0, signal = -1, ref = 1}, switched = true}
#28 0xffffffff in QCoreApplication::notify(QObject*, QEvent*) (this=<optimized out>, receiver=<optimized out>, event=<optimized out>)
    at kernel/qcoreapplication.cpp:997
        d = <optimized out>
#29 0xffffffff in QCoreApplication::notifyInternal(QObject*, QEvent*) (this=0x12ceb58, receiver=receiver@entry=0x17e2830, event=event@entry=0x17d7458)
    at kernel/qcoreapplication.cpp:935
        threadData = 0x12cec00
        loopLevelCounter = {threadData = 0x12cec00}
        result = false
        cbdata = {0x17e2830, 0x17d7458, 0xbebfe65f}
        d = <optimized out>
#30 0xffffffff in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (event=0x17d7458, receiver=0x17e2830)
    at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237
        e = 0x17d7458
        pe = <optimized out>
        r = 0x17e2830
        unlocker = {m = <synthetic pointer>}
        event_deleter = {d = 0x17d7458}
        __PRETTY_FUNCTION__ = "static void QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)"
        locker = {val = 19721244}
        startOffset = 0
        i = <optimized out>
        cleanup = 
          {receiver = 0x0, event_type = 0, data = 0x12cec00, exceptionCaught = true}
#31 0xffffffff in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x12cec00) at kernel/qcoreapplication.cpp:1539
        e = 0x17d7458
        pe = <optimized out>
        r = 0x17e2830
        unlocker = {m = <synthetic pointer>}
        event_deleter = {d = 0x17d7458}
        __PRETTY_FUNCTION__ = "static void QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)"
        locker = {val = 19721244}
        startOffset = 0
        i = <optimized out>
        cleanup = 
          {receiver = 0x0, event_type = 0, data = 0x12cec00, exceptionCaught = true}
#32 0xffffffff in QCoreApplication::sendPostedEvents(QObject*, int) (receiver=receiver@entry=0x0, event_type=event_type@entry=0)
    at kernel/qcoreapplication.cpp:1397
        data = <optimized out>
#33 0xffffffff in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x12ec7b8) at kernel/qeventdispatcher_glib.cpp:279
        source = 0x12ec7b8
#34 0xffffffff in g_main_context_dispatch (context=0x12ecf30)
    at /build/buildd/glib2.0-2.43.3/./glib/gmain.c:3122
        dispatch = 
    0xb647fc4d <postEventSourceDispatch(GSource*, GSourceFunc, gpointer)>
        prev_source = 0x0
        was_in_call = 0
        user_data = 0x0
        callback = 0x0
        cb_funcs = <optimized out>
        cb_data = 0x0
        need_destroy = <optimized out>
        source = 0x12ec7b8
        current = 0x13b8f30
        i = 0
#35 0xffffffff in g_main_context_dispatch (context=context@entry=0x12ecf30)
    at /build/buildd/glib2.0-2.43.3/./glib/gmain.c:3737
#36 0xffffffff in g_main_context_iterate (context=context@entry=0x12ecf30, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.43.3/./glib/gmain.c:3808
        max_priority = 0
        timeout = 0
        some_ready = 1
        nfds = <optimized out>
        allocated_nfds = <optimized out>
        fds = 0x1811ee8
#37 0xffffffff in g_main_context_iteration (context=0x12ecf30, may_block=1)
    at /build/buildd/glib2.0-2.43.3/./glib/gmain.c:3869
        retval = <optimized out>
#38 0xffffffff in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x12ec8b0, flags=...)
    at kernel/qeventdispatcher_glib.cpp:426
        d = 0x12eccb0
        canWait = true
        savedFlags = {i = 0}
        result = <optimized out>
#39 0xffffffff in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=0xbebfe82c, flags=...) at kernel/qeventloop.cpp:212
        locker = {val = 19721368}
        __PRETTY_FUNCTION__ = "int QEventLoop::exec(QEventLoop::ProcessEventsFlags)"
        ref = {d = 0x1811468, locker = @0xbebfe7d4, exceptionCaught = true}
        d = 0x1811468
#40 0xffffffff in  () at /usr/lib/arm-linux-gnueabihf/libQt5XmlPatterns.so.5
#41 0xffffffff in  () at /usr/lib/arm-linux-gnueabihf/libQt5XmlPatterns.so.5
#42 0xffffffff in QXmlSchema::load(QUrl const&) ()
    at /usr/lib/arm-linux-gnueabihf/libQt5XmlPatterns.so.5
#43 0xffffffff in UserMetricsOutput::GSettingsColorThemeProvider::GSettingsColorThemeProvider(QObject*) (this=0x17e1908, parent=<optimized out>)
    at /build/buildd/libusermetrics-1.1.1+14.10.20141020/src/libusermetricsoutput/GSettingsColorThemeProvider.cpp:49
        schemaFile = {static null = {<No data fields>}, d = 0x1811668}
        baseDir = <optimized out>
        __for_range = 
              @0x17e1910: {<QList<QString>> = {{p = {static shared_null = {ref = {atomic = {_q_value = -1}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x1811380}, d = 0x1811380}}, <No data fields>}
#44 0xffffffff in UserMetricsOutput::UserMetrics::getInstance() ()
    at /build/buildd/libusermetrics-1.1.1+14.10.20141020/src/libusermetricsoutput/UserMetrics.cpp:43
        dbusConnection = 
          {static staticMetaObject = {d = {superdata = 0x0, stringdata = 0xb5f496cc <qt_meta_stringdata_QDBusConnection>, data = 0xb5f495a8 <qt_meta_data_QDBusConnection>, static_metacall = 0x0, relatedMetaObjects = 0x0, extradata = 0x0}}, d = 0x132b3f0}
#45 0xffffffff in QQmlType::SingletonInstanceInfo::init(QQmlEngine*) ()
    at /usr/lib/arm-linux-gnueabihf/libQt5Qml.so.5
#46 0xffffffff in QV4::QmlTypeWrapper::get(QV4::Managed*, QV4::StringRef, bool*) () at /usr/lib/arm-linux-gnueabihf/libQt5Qml.so.5
#47 0xffffffff in QV4::Runtime::getProperty(QV4::ExecutionContext*, QV4::ValueRef, QV4::StringRef) () at /usr/lib/arm-linux-gnueabihf/libQt5Qml.so.5
#48 0xffffffff in  ()

Revision history for this message

Michael Terry (mterry) wrote on 2015-02-12:

#2

Looks like a bad interaction between libusermetrics and dbus that results in a mutex lock...

Revision history for this message

Michael Terry (mterry) wrote on 2015-02-12:

#3

Hmm, neither of those packages changed recently. But nor did unity8... I doubt this is unity8's direct fault.

summary:

- unity8 sometimes fails to respond to com.canonical.UnityGreeter IsActive
+ unity8 sometimes hangs on boot

Revision history for this message

Michał Sawicz (saviq) wrote on 2015-02-12:

#4

Bugs #1417773 and #1418707 show similar dbus-related lockups :/

Revision history for this message

Michael Terry (mterry) wrote on 2015-02-12:

#5

Interesting. They may be the same bug. But thankfully, this version of it is easily reproducable. Just flash and boot until you hit it.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-02-12:

#6

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

Changed in unity8 (Ubuntu):
status:	New → Confirmed

Revision history for this message

Michał Sawicz (saviq) wrote on 2015-03-06:

#7

gdb.txt Edit (49.6 KiB, text/plain)

I got a symbolic trace out of all the threads. It seems to be a dbus lock between usermetrics and networkmanager bits.

We suspect a relation to QTBUG https://bugreports.qt.io/browse/QTBUG-44836.

Changed in unity8 (Ubuntu):
status:	Confirmed → Triaged
importance:	Undecided → High
assignee:	nobody → Michał Sawicz (saviq)

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-06:

#8

Yeah my current guess is that QDBusConnectionPrivate::connectSignal doesn't play well with dbus being used from other threads, but need more investigation

Michał Sawicz (saviq) on 2015-03-06

Changed in unity8 (Ubuntu):
assignee:	Michał Sawicz (saviq) → Albert Astals Cid (aacid)
status:	Triaged → In Progress

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-09:

#9

Have been using https://codereview.qt-project.org/#/c/103738/ (and all the pre-requisite patches) for a while and they seem to fix the issues i've been having with dbus deadlocks

Revision history for this message

Michał Sawicz (saviq) wrote on 2015-03-12:

#10

https://codereview.qt-project.org/#/c/107969/ is a simpler proposal that got merged into 5.4 already, we should backport that.

Changed in unity8 (Ubuntu):
status:	In Progress → Invalid
assignee:	Albert Astals Cid (aacid) → nobody
Changed in qtbase-opensource-src (Ubuntu):
assignee:	nobody → Timo Jyrinki (timo-jyrinki)

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-18:

#11

So, 107969 broke things and couldn't be landed. We landed Qt 5.4.1 now, open to new suggestions that are bullet proof.

Timo Jyrinki (timo-jyrinki) on 2015-03-18

Changed in qtbase-opensource-src (Ubuntu):
status:	New → Incomplete

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-18:

#12

Timo if you could create a silo with
https://codereview.qt-project.org/#/c/102762/
https://codereview.qt-project.org/#/c/103731/
https://codereview.qt-project.org/#/c/103732/
https://codereview.qt-project.org/#/c/103733/
https://codereview.qt-project.org/#/c/103734/
https://codereview.qt-project.org/#/c/103735/
https://codereview.qt-project.org/#/c/103736/
https://codereview.qt-project.org/#/c/103737/
https://codereview.qt-project.org/#/c/103738/

It'd be great, suposedly that will land in Qt 5.5 and makes all the dbus threading "better"

Timo Jyrinki (timo-jyrinki) on 2015-03-18

Changed in qtbase-opensource-src (Ubuntu):
status:	Incomplete → Confirmed

Revision history for this message

Francis Ginther (fginther) wrote on 2015-03-18:

#13

Another boottest failure, this one seen with krillin image 152:

https://jenkins.qa.ubuntu.com/job/vivid-boottest-webbrowser-app/3/console

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-20:

#14

Albert's list of cherry-picked patches testable in vivid-021 landing silo together with bug #1431798 fix.

Michał Sawicz (saviq) on 2015-03-20

Changed in qtbase-opensource-src (Ubuntu):
status:	Confirmed → In Progress

Revision history for this message

Michał Sawicz (saviq) wrote on 2015-03-20:

#15

Without silo 21, I was able to get the deadlock with 6-8 reboots. With the silo, no deadlock in 30 reboots and a wipe.

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-24:

#16

The current set of qtbase DBus patches reliably regress when running UITK autopilot tests: http://people.canonical.com/~tjyrinki/qt5/fail/

The qtbase update - current version - has now moved to silo 018 to be able to land the qtdeclarative update from silo 021 still.

Changed in qtbase-opensource-src (Ubuntu):
status:	In Progress → Incomplete

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-24:

#17

Two more patches that are part of the patchset and would make sense having
https://codereview.qt-project.org/#/c/103739/
https://codereview.qt-project.org/#/c/103740/

Timo Jyrinki (timo-jyrinki) on 2015-03-24

Changed in qtbase-opensource-src (Ubuntu):
status:	Incomplete → In Progress

Jean-Baptiste Lallement (jibel) on 2015-03-24

Changed in qtbase-opensource-src (Ubuntu):
importance:	Undecided → Critical

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-24:

#18

Adding libusermetrics as upgrade of it in http://people.canonical.com/~ogra/touch-image-stats/106.changes apparently caused the problem. However, it's probably just because libusermetrics started using DBus as explained in comment #7. The Qt bug itself is probably an old one.

If fixing Qt seems a time consuming process, an option would be to revert the part of the libusermetrics upgrade that triggers the bug.

Also adding autopilot as at least the current set of patches regressed on running Autopilot tests which may mean Autopilot is relying on old behavior and the patches themselves might be correct. We'll know more when the new 2 patches have built and tests run.

Changed in libusermetrics (Ubuntu):
status:	New → Incomplete
Changed in autopilot (Ubuntu):
status:	New → Incomplete

Revision history for this message

Francis Ginther (fginther) wrote on 2015-03-24:

#19

Some more boottest failures, these with krillin image 158

https://jenkins.qa.ubuntu.com/job/vivid-boottest-language-pack-touch-zh-hant/3/console
https://jenkins.qa.ubuntu.com/job/vivid-boottest-language-pack-touch-ru/3/console

Revision history for this message

Francis Ginther (fginther) wrote on 2015-03-24:

#20

And some more with 158:

https://jenkins.qa.ubuntu.com/job/vivid-boottest-language-pack-touch-ca/4/console
https://jenkins.qa.ubuntu.com/job/vivid-boottest-language-pack-touch-nl/5/console
https://jenkins.qa.ubuntu.com/job/vivid-boottest-language-pack-touch-sk/4/console
https://jenkins.qa.ubuntu.com/job/vivid-boottest-language-pack-touch-sv/3/console
https://jenkins.qa.ubuntu.com/job/vivid-boottest-language-pack-touch-uk/3/console

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-25:

#21

I ran some Autopilot testing last night and continuing a bit now . The two new patches do not fix the AP problems. As examples:

- Archive image (#145):
* UITK: 1-2 AP failures
* webbrowser-app: 1-2 AP failures
* calculator: 0 AP failures
* ubuntu-system-settings: 0 AP failures

- Image (#147) added with silo 018 (qtbase DBus patches)
* UITK: 7-8 failures (similar to earlier #145 + previous qtbase DBus fix build)
* webbrowser-app: 5-7 failures
* calculator: 2 failures
* ubuntu-system-settings: 16 AP failures (only 1 run done)

Details at http://people.canonical.com/~tjyrinki/qt5/fail/qtbase_ubuntu5/

Even if the qtbase patches themselves would be correct and functioning well and they just happen to make Autopilot break, we can't let Autopilot regress so badly. Either there should be something more done to Qt or an Autopilot landing fixing the issues should be put to the same silo.

As for libusermetrics, the diff for its landing in #106 is at http://launchpadlibrarian.net/198152771/libusermetrics_1.1.1%2B14.10.20141020-0ubuntu1_1.1.1%2B15.04.20150219-0ubuntu1.diff.gz

Changed in autopilot (Ubuntu):
status:	Incomplete → New
Changed in qtbase-opensource-src (Ubuntu):
status:	In Progress → Incomplete

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-25:

#22

testfail.txt Edit (6.6 KiB, text/plain)

All the failure traces seem to be stating that autopilot wouldn't be able to launch the application. In case of eg address-book-app once a test fails, all subsequent tests fail too. In case of eg UITK, it's just that random tests fail.

Here's a simplified test case:

while [ 1 ] ; do phablet-test-run ubuntuuitoolkit.tests.custom_proxy_objects.test_header.SectionsTestCase.test_select_sections_with_sections_disabled ; done

When the failure happens, the application seems to start fine, but autopilot thinks it did not. After waiting for some while (~38 seconds as opposed to ~6 seconds on successful run) it errors out.

Without silo 018 the above test case never fails.

Timo Jyrinki (timo-jyrinki) on 2015-03-25

description:

updated

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-25:

#23

Timo, can you try running the tests again with https://code.launchpad.net/~aacid/autopilot/dbus_search_no_seen_connections/+merge/254109 ? I've been running

while [ 1 ] ; do phablet-test-run ubuntuuitoolkit.tests.custom_proxy_objects.test_header.SectionsTestCase.test_select_sections_with_sections_disabled ; done

with it for over an hour and had no failure.

Revision history for this message

Richard Huddie (rhuddie) wrote on 2015-03-25:

#24

I tried reproducing this issue on silo 18 using address_book_app.tests.test_add_contact.TestAddContact.test_go_to_add_contact.

The test failed on the 10th attempt in the same way as in the logs: http://people.canonical.com/~tjyrinki/qt5/fail/qtbase_ubuntu5/ap-2015_03_24-21_48_11-address_book_app-1-018.tests

Watching the test, the address-book-app froze as it was launching, displaying a frozen spinner on the loading screen. Autopilot then timed out waiting for the app to launch and reported the introspection failure.

Subsequent tests then failed with the maliit-server error as reported in the same logs.

The only crash file reported was: _usr_lib_telepathy_mission-control-5.32011.crash

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-26:

#25

Richard, which hardware are you using?

Can you try reproducing the issue again and then gdb'ing in to the frozen app and posting a backtrace? I've been running it in a loop for minutes and had nothing.

Revision history for this message

Richard Huddie (rhuddie) wrote on 2015-03-26:

#26

I was using mako devel-proposed image #148 with the silo installed.

I'll try and reproduce again and get some more info.

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-26:

#27

I've reflashed the device so this is with vivid #150 + 018. The MP in #23 (just adjusted for AP 1.5 branch) is now in the 018 PPA.

The simplified test case seems fixed for me too, but unfortunately it'd look like running a whole suite like phablet-test-run ubuntuuitoolkit simply hangs at some point - in the sense that test app loads but nothing further happens. Killing the process gets the tests to continue. This ended up with: http://people.canonical.com/~tjyrinki/qt5/fail/qtbase_ubuntu5/ap-2015_03_26-09_54_27-ubuntuuitoolkit-1-018.tests - potentially less failures (6) than before AP update, but more than before qtbase update.

The second UITK run with qtbase + AP seemingly went uninterrupted further, but still with more (7) AP failures compared to before updating qtbase. However, at the end of the run it seemed like the test app was hanging - I tried gdb attaching to it, realized I didn't have debug symbols and detached. After this it seemed the it continued and the testing completed immediately: http://people.canonical.com/~tjyrinki/qt5/fail/qtbase_ubuntu5/ap-2015_03_26-09_54_27-ubuntuuitoolkit-2-018.tests

So it'd seem the AP patch does change behavior and fixes the simple testcase, but is not the real fix. Or it's possible it fixes the AP end but there is some sort hanging issue with the updated Qt.

Revision history for this message

Richard Huddie (rhuddie) wrote on 2015-03-26:

#28

I tried again to reproduce the issue, using #150 + silo 18 (including autopilot update). I've not been able to reproduce it again after many retries.

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-26:

#29

running phablet-test-run ubuntuuitoolkit hanged for me with https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1436860 not sure it's caused by these patches or just happens now more becuase things are faster, trying silo 13 as per mir guys suggetsion

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-26:

#30

webbrowser-app with the new qtbase + AP http://people.canonical.com/~tjyrinki/qt5/fail/qtbase_ubuntu5/ap-2015_03_26-15_57_41-webbrowser_app-1-018.tests (3 failures, between 1-2 without 018 and 5-7 with 018 before AP was updated)

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-26:

#31

So i tried with silo 13 two times in a row and all the SDK autopilot tests passed fine.

Revision history for this message

Francis Ginther (fginther) wrote on 2015-03-27:

#32

A boottest failure with image 160:

http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/BootTest/job/vivid-boottest-ofono/1/console

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-27:

#33

Unfortunately I couldn't reproduce success with my mako last night with 018 (qtbase + autopilot) + 013 (Mir 0.12.1) + rsalveti (glibc fix). Here are the results until aborted: http://people.canonical.com/~tjyrinki/qt5/fail/vivid-ap-mir013/ - for example 6 + 8 failures in UITK.

I'll try again with the new #151 image including Mir, glibc and other things + 018, but I doubt it'll change this picture.

@Albert did you test on krillin or mako?

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-27:

#34

krillin.

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-27:

#35

Looking in more detail, it seems the new Mir may have helped mako in the address-book-app "hang" case, even though for example UITK and webbrowser-app still have more failures. The address-book-app that failed reliably several times earlier, now in the comment #33 linked results failed only 1 test on both runs, similar to what happens on archive.

Rerunning now on image #151 + silo 018, UITK still seems problematic which is not a surprise since it should be similar to yesterday's combination of #150 + silo 018 + silo 013 + rsalveti PPA. This time executing tests seemed to have hanged at one point, and touching the screen interestingly resulted in Unity 8 crashing: http://people.canonical.com/~tjyrinki/qt5/fail/mako151_plus_018/_usr_bin_unity8.32011.crash

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-27:

#36

The crash in http://people.canonical.com/~tjyrinki/qt5/fail/mako151_plus_018/_usr_bin_unity8.32011.crash is mir/unity8 crashing because they disagree on touch event delivery, nothing to do with dbus patches.

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-27:

#37

https://bugs.launchpad.net/qtmir/+bug/1437357 is that crash

Łukasz Zemczak (sil2100) on 2015-03-30

tags:

added: lt-blocker lt-category-visible

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-30:

#38

The earlier simplified test case does not fail anymore or at least not easily. Whether on stock image or using the PPA, the problem with running the same test over and over is that Unity8 crashes or restarts sooner or later when running the command, for example that crasher bug noticed.

I ran a new baseline set of results on Saturday with image #153 to see how the situation looks like on mako after the Mir, UITK, glibc landings. It's still the same - UITK, webbrowser, calculator, ubuntu-system-settings, ubuntu-weather-app are good examples of suites that 100% pass on stock image. They gain respectively 4/9, 3/6, 1/1, 4/7, 3/4 tests failing based on two autopilot runs with the PPA 018 in use. The failures are random, ie the test failing changes depending on the run.

In other words, to reproduce the autopilot problem when using the PPA you can run any of the following on mako:
phablet-test-run ubuntuuitoolkit
phablet-test-run webbrowser_app
phablet-test-run ubuntu_calculator_app
phablet-test-run ubuntu_system_settings
phablet-test-run ubuntu_weather_app

Prepare the device by first running on device sudo apt install ubuntu-ui-toolkit-autopilot webbrowser-app-autopilot ubuntu-system-settings-autopilot python3-lxml

Timo Jyrinki (timo-jyrinki) on 2015-03-30

description:	updated
description:	updated
description:	updated
description:	updated
description:	updated
description:	updated

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-30:

#39

My opinion is that all those failures where probably there already since the ones i've been able to find/replicate don't seem qdbus related

Now why is this happening with these patches? These patches make qdbus serialize much less on the main thread, i.e. things are executed more in different threads, this decreases the points of sincronization qdbus caused on the main thread without these patches and so threads run more "freely"

This can make this that were previously race hit the races and thus cause the autopilot tests to randomly fail or not depending if the race is fixed or not

Now i can't say that none of these failures are qdbus related since i've not been able to reproduce them all, would need help from the people with expertise on those particular apps to have a look at them.

Revision history for this message

Francis Ginther (fginther) wrote on 2015-03-30:

#40

A boottest failure with image 167 (krillin):

https://jenkins.qa.ubuntu.com/job/vivid-boottest-dialer-app/3/console

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-30:

#41

Addition to my previous comment, for weather + calculator apps you need to run phablet-click-test-setup from the host or one at a time:
phablet-click-test-setup --click com.ubuntu.calculator
phablet-click-test-setup --click com.ubuntu.weather

The other tests come from the mentioned deb packages.

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-30:

#42

And one more addition to anyone not constantly running autopilot and aware of the pre-requirements:

phablet-config autopilot --dbus-probe enable

is needed before running tests. This is documented at https://wiki.ubuntu.com/Touch/Testing#Running_Click_tests and also done automatically for me as I use UI Toolkit's test script to run my AP Testing: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/uitk_test_plan.sh

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-03-30:

#43

thread_stacktrace Edit (15.7 KiB, text/plain)

Ok, got one thread deadlock in the calculator app that seems dbus related, investigating a bit more

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-31:

#44

As per Albert's instructions I took three updated patches and five new patches from upstream. Four of them needed rebasing for Qt 5.4, but a local build now finished and a PPA build with version number ubuntu6~vivid1~test1 is now building in 018 PPA.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-03-31:

#45

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

Changed in autopilot (Ubuntu):
status:	New → Confirmed

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-04-02:

#46

The bug is now finally confirmed as fixed without regressions in autopilot tests, in the silo 018 (qtbase version ending ubuntu6). The silo is now handed off to QA.

Changed in qtbase-opensource-src (Ubuntu):
status:	Incomplete → In Progress
Changed in libusermetrics (Ubuntu):
status:	Incomplete → Invalid

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-04-02:

#47

Bad news, tried to start Plasma 5 with the patches to be greated by a zillion of crashing processes, here a backtrace of one of them

Thread 1 (Thread 0x7f658362a780 (LWP 10972)):
[KCrash Handler]
#6 0x00007f6583662168 in QDBusConnectionPrivate::shouldWatchService(QString const&) (this=this@entry=0x0, service=...) at qdbusintegrator.cpp:2310
#7 0x00007f6583662ce2 in QDBusConnectionPrivate::watchService(QString const&, QFlags<QDBusServiceWatcher::WatchModeFlag>, QObject*, char const*) (this=0x0, service=..., mode=..., obj=0xb226b8, member=member@entry=0x7f65836ac300 "1_q_serviceOwnerChanged(QString,QString,QString)") at qdbusintegrator.cpp:2315
#8 0x00007f65836a8695 in QDBusServiceWatcher::addWatchedService(QString const&) (service=..., this=<optimized out>) at qdbusservicewatcher.cpp:103
#9 0x00007f65836a8695 in QDBusServiceWatcher::addWatchedService(QString const&) (this=<optimized out>, newService=...) at qdbusservicewatcher.cpp:283
#10 0x00007f653fde3254 in () at /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_touchpad.so
#11 0x00007f653fdcbd38 in () at /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_touchpad.so
#12 0x00007f65823bd608 in KPluginFactory::create(char const*, QWidget*, QObject*, QList<QVariant> const&, QString const&) () at /usr/lib/x86_64-linux-gnu/libKF5CoreAddons.so.5
#13 0x00007f65832ece7d in () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#14 0x00007f65832ed45f in () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#15 0x00007f65832edc88 in () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#16 0x00007f65832eec53 in () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#17 0x00007f65832ef03a in kdemain () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#18 0x00007f6582f38a40 in __libc_start_main (main=0x400720 <main>, argc=1, argv=0x7fff13734958, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff13734948) at libc-start.c:289
#19 0x000000000040074e in _start ()

Also konsole is now failing to start (this may be a misuse of api on KUniqueApplication) but still not good to regress like that

Bad news, tried to start Plasma 5 with the patches to be greated by a zillion of crashing processes, here a backtrace of one of them

Thread 1 (Thread 0x7f658362a780 (LWP 10972)):
[KCrash Handler]
#6  0x00007f6583662168 in QDBusConnectionPrivate::shouldWatchService(QString const&) (this=this@entry=0x0, service=...) at qdbusintegrator.cpp:2310
#7  0x00007f6583662ce2 in QDBusConnectionPrivate::watchService(QString const&, QFlags<QDBusServiceWatcher::WatchModeFlag>, QObject*, char const*) (this=0x0, service=..., mode=..., obj=0xb226b8, member=member@entry=0x7f65836ac300 "1_q_serviceOwnerChanged(QString,QString,QString)") at qdbusintegrator.cpp:2315
#8  0x00007f65836a8695 in QDBusServiceWatcher::addWatchedService(QString const&) (service=..., this=<optimized out>) at qdbusservicewatcher.cpp:103
#9  0x00007f65836a8695 in QDBusServiceWatcher::addWatchedService(QString const&) (this=<optimized out>, newService=...) at qdbusservicewatcher.cpp:283
#10 0x00007f653fde3254 in  () at /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_touchpad.so
#11 0x00007f653fdcbd38 in  () at /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_touchpad.so
#12 0x00007f65823bd608 in KPluginFactory::create(char const*, QWidget*, QObject*, QList<QVariant> const&, QString const&) () at /usr/lib/x86_64-linux-gnu/libKF5CoreAddons.so.5
#13 0x00007f65832ece7d in  () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#14 0x00007f65832ed45f in  () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#15 0x00007f65832edc88 in  () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#16 0x00007f65832eec53 in  () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#17 0x00007f65832ef03a in kdemain () at /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so
#18 0x00007f6582f38a40 in __libc_start_main (main=0x400720 <main>, argc=1, argv=0x7fff13734958, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff13734948) at libc-start.c:289
#19 0x000000000040074e in _start ()

Also konsole is now failing to start (this may be a misuse of api on KUniqueApplication) but still not good to regress like that

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-04-02:

#48

Indeed the testing was finished only on the phone + Unity 7 desktop (Qt 5 apps only). QA signoff is now put on hold once again because of the Plasma 5 regression.

The phone Autopilot results are at http://people.canonical.com/~tjyrinki/qt5/ap-2015-04-02-mako-156-silo-018/

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-04-08:

#49

Yesterday ubuntu7~test1 was done with http://paste.ubuntu.com/10759851/ - unfortunately no changes in Plasma 5 despite upstream thinking those would address the problem.

Now building ubuntu7~test2 with https://codereview.qt-project.org/#/c/109632/ updated to the latest patch set which was missed earlier.

Revision history for this message

Albert Astals Cid (aacid) wrote on 2015-04-09:

#50

Seems the updated patch indeed fixes the crashes in Plasma 5 startup, but applications using KUniqueApplication like konsole or kfontview fail to start, these applications got a warning before (i.e. without the patchset) that they were misusing qdbus and i think that Qt changing to make them fail to start is "ok" but the problem is us introducing this before Qt does (qt 5.4 vs qt 5.5) and so suddenly/close to the vivid release.

Maybe this patchset could be applied either only to armhf or only to vivid-rtm (if we end up with that solution for this release) so the desktop apps using Qt5 have time to adapt?

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-04-10:

#51

The autopilot tests with ubuntu7~test3 are ready and looking (with unity8 and music-app flaky and could be rerun) good when compared to the stock archive results: http://people.canonical.com/~tjyrinki/qt5/ap-2015-04-09-mako-166-silo-018/. That means there's a good chance this is as good as before for Ubuntu Phone or even better, now that the KDE Plasma 5 also starts without problems too. The remaining problem are the KDE applications using deprecated behavior.

vivid-rtm should be available late next week so this could land there. Modifying the packaging to selectively patch only armhf might be an option but given vivid is <2 weeks from release even that's a bit far-fetched idea at this point. For vivid+1 that could be done so that we're not out of sync with rtm there.

Revision history for this message

Tony Espy (awe) wrote on 2015-04-10:

#52

As the bug description seems to focus on test hangs, and mentions krillin and mako, I want to add that I see this on normal boots of mako ( vivid-proposed / #166 ) and arale ( vivid-proposed / #165 ); roughly 30% of the time.

Pat McGowan (pat-mcgowan) on 2015-04-10

Changed in canonical-devices-system-image:
status:	New → In Progress
importance:	Undecided → Critical
milestone:	none → ww17-2015

Michał Sawicz (saviq) on 2015-04-15

Changed in autopilot (Ubuntu):
status:	Confirmed → Fix Released

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-04-16:

#53

This is still pending on an upstream fix that doesn't break certain KDE apps using deprecated functions. Meanwhile, I can (and will) prepare a landing to vivid-rtm PPA if it seems a fix that can be landed to Ubuntu proper continues to take time.

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-04-18:

#54

With the current build 5.4.1+dfsg-2ubuntu6~rtm~test2 the KDE legacy app situation looks unchanged. Now the phone PPA is enabled so I will start evaluating if the current build would be suitable to there.

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-04-20:

#55

Weekend's test results at http://people.canonical.com/~tjyrinki/qt5/ap-2015-04-18-mako-175-silo-018/

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-04-22:

#56

As an update ~test3 updated ppc64el symbols and "ubuntu7" is a no-change rebuild of ~test3 with a saner version number. Putting forward to QA for further testing and signoff.

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-04-23:

#57

QA has found an app installation problem sometimes happening with the silo 018, fixed at least by removing and re-adding U1 account. I did not see such problem, but I also flashed clean, updated and only then added the U1 account for installing apps so it maybe the reason I was able to install apps without problems.

I did see both with and without the PPA that sometimes adding U1 account in general stalls on vivid, so that's not a regression.

On IRC I got some info about how DBus is used with app installations: "dbus is used to monitor installation progress (for the progress bar in the preview). apps store scope just passes dbus object path to unity8 dash and doesn't interact with dbus directly (at least when it comes to installation); probably unity8/dash logs are first to look at"

I now updated to latest image, added U1 account, installed an app, and then upgraded to silo 018, and I can see the problem now. When I click "Install", dbus.log gets:
---
Activating service name='com.ubuntu.OnlineAccountsUi'
Successfully activated service 'com.ubuntu.OnlineAccountsUi'
---
but unity8-dash.log gets:
---
RequestAccess failed: QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/'")
---

Then when I clicked back arrow from the app page, I got a request for U1 credentials, which I canceled. When I go to u-s-s the U1 account is not there anymore. After adding U1 account, it appears that app installation work smoothly.

It seems to me the pattern is that the U1 account gets removed randomly when a reboot is involved. One time I observed the account had survived a reboot, but disappeared at the moment I clicked "Install". But it seems that without a reboot and with account added app installation seems to work for multiple apps without problems.

I did clean QML cache at one point so it does not seem to be related (also, qtdeclarative isn't touched in the PPA).

After ppa-purging the problem doesn't occur anymore. So the problem has to come from the QDBus changes in the silo, even if those provably fix the Unity 8 hanging issue during boot and no issues were seen in any of the autopilot tests.