[regression] Mir EGL on intel graphics kills nested server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Fix Released
|
Medium
|
Alan Griffiths |
Bug Description
Simpler scenario to reproduce:
1. Take a Zesty system with Intel graphics and Mir trunk
2. Apply lp:~alan-griffiths/mir/dont-handle-nested-input-on-rpc-thread
(To avoid the issue seen in comment #1)
3. Start a host server running mesa-kms (CNR using mesa-x11)
$ sudo bin/mir_demo_server --vt 4 --arw-file --window-manager system-compositor
4. Start a nested server with an EGL client
$ bin/mir_demo_server --no-file --host /tmp/mir_socket --launch bin/mir_
5. Resize the window (Alt-Middle drag) until the display freezes (doesn't take long)
Expect: the display doesn't freeze
Actual: the nested server (step 3) has exited with "intel_
=== original description ===
This is on zesty, with Mir 0.27, MirAL 1.4 and rebuilds of QtMir and USC (in silo 2818 at the time of report)
https:/
https:/
https:/
https:/
with a "live" USB. Steps to reproduce:
1. boot off the USB
2. sudo apt-add-repository ppa:ci-
3. sudo apt update
4. sudo apt upgrade -y
5. sudo service lightdm restart
6. Log out
7. select U8 session
8. sign in as ubuntu/<blank>
8. Search "ter" & down arrow to select Terminal
Lockup
The lockup happens in Unity8's renderer thread, once it calls
eglSwapBuffers after adding the client surface to the scene.
eglSwapBuffers prints a familiar error:
intel_do_
and calls __GI_exit() on the renderer thread, which causes Qt's threads
to block is a awkward way.
So something has changed in Mir 0.27 that Mesa/i915 is unhappy with.
Related branches
- Brandon Schaefer (community): Approve
- Gerry Boland (community): Approve (tentative)
- Mir CI Bot: Approve (continuous-integration)
-
Diff: 16 lines (+6/-0)1 file modifiedsrc/platforms/mesa/server/gbm_platform.cpp (+6/-0)
Changed in mir: | |
status: | Confirmed → In Progress |
Changed in mir: | |
milestone: | none → 0.27.0 |
description: | updated |
Changed in mir: | |
status: | Fix Committed → Fix Released |
This may not be Unity8 specific. I got a similar lockup in miral-shell.
1. Use mir_demo_shell as a host:
$ sudo mir_demo_server --arw-file --vt 4 --window-manager system-compositor
2. Run miral-shell as a guest:
$ miral-app --host /tmp/mir_socket
3. Start egltriangle & eglplasma and start switching, resizing, maximizing etc. After a while it seems the "RPC thread" starts making blocking calls to the client API.
(gdb) info threads unix/syscall- template. S:84 cond_wait@ @GLIBC_ 2.3.2 () unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S:185 cond_wait@ @GLIBC_ 2.3.2 () unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S:185 cond_wait@ @GLIBC_ 2.3.2 () unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S:185 unix/syscall- template. S:84 cond_wait@ @GLIBC_ 2.3.2 () unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S:185 cond_wait@ @GLIBC_ 2.3.2 () unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S:185 unix/syscall- template. S:84 cond_wait@ @GLIBC_ 2.3.2 () unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S:185 cond_wait@ @GLIBC_ 2.3.2 () at ../sysdeps/ unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S:185 unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S: No such file or directory. cond_wait@ @GLIBC_ 2.3.2 () at ../sysdeps/ unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S:185 variable: :wait(std: :unique_ lock<std: :mutex> &) () at /usr/lib/ x86_64- linux-gnu/ libstdc+ +.so.6 c++/6/condition _variable: 99 03e00) at ./src/client/ mir_render_ surface_ api.cpp: 43 create_ render_ surface_ sync (connection= <optimised out>, width=<optimised out>, height=<optimised out>) at ./src/client/ mir_render_ surface_ api.cpp: 126 8540) graphics/ nested/ mir_client_ host_connection .cpp:177 70940, image=...) graphics/ nested/ mir_client_ host_connection .cpp:491 :CursorControll er::update_ cursor_ image_locked( std::unique_ lock<std: :mutex> &) [clone .constprop.589] (this=this@ entry=0x55c1dbe 82f10, lock=...) at ./src/server/ input/cursor_ controller. cpp:248
Id Target Id Frame
* 1 Thread 0x7f1811eafc80 (LWP 4525) "miral-shell" 0x00007f181036e18d in poll () at ../sysdeps/
2 Thread 0x7f180a305700 (LWP 4526) "RPC Thread" pthread_
at ../sysdeps/
3 Thread 0x7f1803fff700 (LWP 4532) "Mir/Snapshot" pthread_
at ../sysdeps/
4 Thread 0x7f18037fe700 (LWP 4533) "Mir/Comp" pthread_
at ../sysdeps/
5 Thread 0x7f1802ffd700 (LWP 4534) "Mir/Input Reade" 0x00007f181036e18d in poll () at ../sysdeps/
6 Thread 0x7f18027fc700 (LWP 4535) "Mir/IPC" pthread_
at ../sysdeps/
7 Thread 0x7f1801ffb700 (LWP 4536) "Mir/IPC" pthread_
at ../sysdeps/
8 Thread 0x7f18017fa700 (LWP 4537) "RPC Thread" 0x00007f181036e18d in poll () at ../sysdeps/
9 Thread 0x7f1800ff9700 (LWP 4538) "miral-shell" pthread_
at ../sysdeps/
(gdb) t 2
[Switching to thread 2 (Thread 0x7f180a305700 (LWP 4526))]
#0 pthread_
185 ../sysdeps/
(gdb) bt
#0 0x00007f180f842510 in pthread_
#1 0x00007f181090580c in std::condition_
#2 0x00007f1810e3c18b in wait () at /usr/include/
#3 0x00007f1810e3c18b in wait_for_result (this=0x7f180a3
#4 0x00007f1810e3c18b in mir_connection_
#5 0x00007f180ffc4f67 in set_cursor_image (image=..., this=0x55c1dbfb
at ./src/server/
#6 0x00007f180ffc4f67 in set_cursor_image (this=0x55c1dbd
at ./src/server/
#7 0x00007f180ffcc076 in mir::input:
#8 0x00007f180ff248...