QObject::startTimer: Timers cannot be started from another thread

Bug #1438126 reported by Albert Astals Cid
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
maliit-framework (Ubuntu)
New
Undecided
Unassigned
qtubuntu (Ubuntu)
New
Undecided
Unassigned

Bug Description

When blanking/unblanking the screen on the phone you get

QObject::startTimer: Timers cannot be started from another thread

It comes from
#0 0xffffffff in QObject::startTimer(int, Qt::TimerType) () at /home/phablet/chroot/home/phablet/qtbase-opensource-src-5.4.1+dfsg/lib/libQt5Core.so.5
#1 0xffffffff in QTimer::start() () at /home/phablet/chroot/home/phablet/qtbase-opensource-src-5.4.1+dfsg/lib/libQt5Core.so.5
#2 0xffffffff in MInputContext::hideInputPanel() () at /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforminputcontexts/libmaliitphabletplatforminputcontextplugin.so
#3 0xffffffff in () at /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqpa-ubuntumirclient.so
#4 0xffffffff in () at /usr/lib/arm-linux-gnueabihf/libmirclient.so.8
#5 0xffffffff in () at /usr/lib/arm-linux-gnueabihf/libmirclient.so.8
#6 0xffffffff in () at /usr/lib/arm-linux-gnueabihf/libmirclient.so.8
#7 0xffffffff in () at /usr/lib/arm-linux-gnueabihf/libmirclient.so.8
#8 0xffffffff in () at /usr/lib/arm-linux-gnueabihf/libmirclient.so.8
#9 0xffffffff in () at /usr/lib/arm-linux-gnueabihf/libmircommon.so.3
#10 0xffffffff in () at /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#11 0xffffffff in start_thread () at /lib/arm-linux-gnueabihf/libpthread.so.0
#12 0xffffffff in () at ../sysdeps/unix/sysv/linux/arm/clone.S:89

This means basically that the start() call to the timer in MInputContext::hideInputPanel is being ignored

Can be "relatively" easily fixed in two ways:
 * Make the sipHideTimer.start(); in MInputContext::hideInputPanel be a QMetaObject::invokeMethod
 * Make the integration->inputContext()->hideInputPanel(); call in aboutToStopCallback be a QMetaObject::invokeMethod to QInputMethod::hide

The question is though if this actually needs fixing since there seems to be nothing broken? So maybe removing the integration->inputContext()->hideInputPanel(); call in aboutToStopCallback is the actual fix?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.