Mali deadlock with X server grab

Hi dsd, I apologize no one has got back to you on your two questions yet, I am highlighting them to the team now. We'll get a response to you asap.

Best wishes,

Ellie

HI dsd,

Have you managed to solve this issue? If not would it be possible to help us understand the problem more by providing the information Frank mentions above.

Thanks.

However, I believe this threaded model that has bitten here is part of a wider design problem that is biting us in other areas such as in Bad interaction with DRI2 for vsync

So it would still be worth working on the larger problem. Right now Mali starts a new thread and a new X connection, and uses that new thread/connection to perform SwapBuffers. This seems bizarre, given that SwapBuffers is an asynchronous operation that should always return immediately, but as we see in the other thread, it looks like there was some confusion here and the original Mali stack has implemented this as a synchronous, blocking op (which explains why libMali would then create a new thread and connection). Would be great if that can be fixed.

We would love to try r4p0 and in fact I already downloaded the source code you mentioned, compiled it and checked that it loads - great. However we cannot actually test this until someone provides us with the r4p0 version of libMali/libEGL/libGLESv2. Hardkernel have some DDK licensing difficulties at the moment so they can't provide this. If ARM could provide a new binary libMali for Mali-400/armhf/Linux/X11/UMP it would be ideal.

Thanks,

Daniel

Hi dsd

mali driver may create another "Display" through XOpenDisplay, and use its return value to do swap, so if XGrabServer is used, deadlock may happen.

I think the root cause is that gnome-shell just passes EGL_DEFAULT_DISPLAY into eglGetDisplay(), so mali driver doesn't have a X connection to do proper operations instead of create an own one.

Can you please have a try with the following in gnome-shell:

Display* dpy = XOpenDisplay(...);

...

EGLDisplay egl_dpy = eglGetDisplay((EGLNativeDisplayType)dpy);

....

so that mali driver will use this "dpy", and it will not cause deadlock no matter XGrabServer is used or not.

https://git.gnome.org/browse/cogl/tree/cogl/cogl-xlib-renderer.c#n176

https://git.gnome.org/browse/cogl/tree/cogl/winsys/cogl-winsys-egl-x11.c#n265

but let's take a more simplistic example: es2_info from mesa-demos. This one very clearly does what you say. http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles1/es1_info.c#n227

Running this in gdb, log below, I very clearly observe the following:

1. mali creates threads when eglInitialize is called
2. mali calls XOpenDisplay (for a 2nd time) even though we correctly passed in an X display  as you suggested

# gdb es2_info
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
...
Reading symbols from /root/mesa-demos-8.0.1+git20110129+d8f7d6b/src/egl/opengles2/es2_info...done.
(gdb) b eglInitialize
Breakpoint 1 at 0x8b08
(gdb) b XOpenDisplay
Breakpoint 2 at 0x8b50
(gdb) run
Starting program: /root/mesa-demos-8.0.1+git20110129+d8f7d6b/src/egl/opengles2/es2_info 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Breakpoint 2, 0xb6e476b4 in XOpenDisplay ()
   from /usr/lib/arm-linux-gnueabihf/libX11.so.6
(gdb) info threads
  Id   Target Id         Frame 
* 1    Thread 0xb6ff83c0 (LWP 10531) "es2_info" 0xb6e476b4 in XOpenDisplay ()
   from /usr/lib/arm-linux-gnueabihf/libX11.so.6
(gdb) bt
#0  0xb6e476b4 in XOpenDisplay ()
   from /usr/lib/arm-linux-gnueabihf/libX11.so.6
#1  0x0000903e in main (argc=1, argv=0xbefff744) at es2_info.c:246

So far, es2_info called XOpenDisplay, it will later pass this display into Mali. We have just 1 thread. Good.

(gdb) c
Continuing.

Breakpoint 1, 0xb6f6244a in eglInitialize ()
   from /usr/lib/arm-linux-gnueabihf/libGLESv2.so
(gdb) info threads
  Id   Target Id         Frame 
* 1    Thread 0xb6ff83c0 (LWP 10531) "es2_info" 0xb6f6244a in eglInitialize ()
   from /usr/lib/arm-linux-gnueabihf/libGLESv2.so
(gdb) bt
#0  0xb6f6244a in eglInitialize ()
   from /usr/lib/arm-linux-gnueabihf/libGLESv2.so
#1  0x00008cd0 in main (argc=1, argv=0xbefff744) at es2_info.c:259

Now es2_info calls eglInitialize. Still only 1 thread. So far so good. Let's step to the next line in es2_info

(gdb) n
Single stepping until exit from function eglInitialize,
which has no line number information.
[New Thread 0xb6be6470 (LWP 10534)]
[New Thread 0xb63e6470 (LWP 10535)]

Breakpoint 2, 0xb6e476b4 in XOpenDisplay ()
   from /usr/lib/arm-linux-gnueabihf/libX11.so.6
(gdb) bt          
#0  0xb6e476b4 in XOpenDisplay ()
   from /usr/lib/arm-linux-gnueabihf/libX11.so.6
#1  0xb6f67326 in __egl_platform_initialize ()
   from /usr/lib/arm-linux-gnueabihf/libGLESv2.so
#2  0xb6f62d0c in __egl_main_open_mali ()
   from /usr/lib/arm-linux-gnueabihf/libGLESv2.so
#3  0xb6f61cb0 in _egl_initialize ()
   from /usr/lib/arm-linux-gnueabihf/libGLESv2.so
#4  0xb6f6246c in eglInitialize ()
   from /usr/lib/arm-linux-gnueabihf/libGLESv2.so
#5  0x00008cd0 in main (argc=1, argv=0xbefff744) at es2_info.c:259
(gdb) info threads
  Id   Target Id         Frame 
  3    Thread 0xb63e6470 (LWP 10535) "es2_info" __libc_do_syscall ()
    at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:43
  2    Thread 0xb6be6470 (LWP 10534) "es2_info" 0xb6dd0928 in ioctl ()
    at ../sysdeps/unix/syscall-template.S:81
* 1    Thread 0xb6ff83c0 (LWP 10531) "es2_info" 0xb6e476b4 in XOpenDisplay ()
   from /usr/lib/arm-linux-gnueabihf/libX11.so.6

Now..before we hit the next line in es2_info (i.e. during eglInitialize still), 2 threads were created, and Mali ran XOpenDisplay() again. There should be no need for this XOpenDisplay call to happen, because we already passed in the X display to eglGetDisplay. But mali goes ahead and runs XOpenDisplay() anyway and it is my suspicion that it then later uses this connection from the "SwapBuffers thread".

I also think the reasons for creating an internal Mali thread are not totally valid. It seems like this internal thread is there just to run SwapBuffers calls? But in a correctly implemented setup, the SwapBuffer is asynchronous, it does not block, so there is no clear reason why this would need it's own thread. This is explained a bit in Bad interaction with DRI2 for vsync

I'm glad to hear that you are looking into solving this going forward - without this superflous extra thread, Mali will be better and more reliable as a result.