keyboard stops working, maliit and unity8 consuming cpu

[Jonas G. Drange]

Phone:
Arale @ rc-proposed #61

Reproduce:
1. Open Messaging App
2. Start a conversation
3. Tap messaging area to show keyboard
4. Tap camera icon
5. Take picture and accept it

What happens:
Keyboard goes away and does not come back when focusing the text input.

What should happen:
The keyboard should function normally

Note: only a reboot seems to fix this

[Sturm Flut (sturmflut)]

Confirmed on arale rc-proposed r58.

[Launchpad Janitor (janitor)]

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

[Tiago Salem Herrmann (tiagosh)]

I can reproduce the same bug here on both krillin and arale.
I noticed that if I kill maliit-server osk is back to normal. I also noticed that both maliit-server and unity8 are consuming a lot of cpu, and after killing maliit-server, both processes are back to normal.

[Albert Astals Cid (aacid)]

Maybe duplicate of 1470780 ?

[Launchpad Janitor (janitor)]

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

[Michael Sheldon (michael-sheldon)]

This seems to be triggered specifically by the fact that camera-app is fullscreen (so possibly also related to bug 1470780 as Albert suggests, since the media player is also fullscreen, however I haven't been able to reproduce that one myself yet). After modifying camera-app to launch in non-fullscreen mode the bug doesn't get triggered.

Attaching GDB to maliit-server shows that it seems to be stuck waiting for a mutex, but without enough debugging info to show where that call originated:

#0 0xb6033d44 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1 0xb602f6b0 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#2 0xb68ba0d8 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#3 0xb64cf9ee in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Quick.so.5
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Michael Sheldon (michael-sheldon)]

Seems the problem was triggered by a change in qtubuntu, with the new faster resizing implementation:

http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/revision/266

For some reason this results in the keyboard surface stuck in a loop constantly swapping buffers when returning to the messaging app (the keyboard has to be visible prior to the image import from the camera app, so that its surface gets resized when going to the fullscreen camera and then back to the normal sized messaging window). With that change reverted everything behaves normally.

[Daniel d'Andrada (dandrader)]

The last mir-surface-resize event maliit-server gets is of size (768, 1242). Which is midway between fullscreen and regular (non-fullscreen) window size. The switch between fullscreen and regular is animated so it gets many resizes in between during the transition.

The logic is for the client (maliit-server) to swap surface buffers until it gets a buffer with the promised size. Problem is that it never gets a buffer of such size, they're all (768,1222), which is the final non-fullscreen window size. So it keeps swapping buffers for all eternity.

[Daniel d'Andrada (dandrader)]

anpok's theory is that the render thread is so busy swapping buffers that it doesn't give a change for the main thread to process the pending resize events that came from mir. Because if it did, it would have known that the last resize event had size (768,1222), which matches the size of the buffers the render thread is getting.