Prediction is that it is a mutex deadlock within X11 protocol error handling. Attach gdb and grab a bt.

Thanks for the suggestion. Can you give me some more detailed indication on how to proceed (or a pointer to a place where they may be ready available)?

Wait for the hang in matlab. Run "ps ax" to find the matlab process (there may be more than one, if so repeat until you find something interesting!), then run "gdb --pid <matlib pid>". Inside gdb, run "bt full", that's the output that should tell us what's causing the hang.

To get best results out of gdb, requires having the debug symbols for the packages. Ideally everything used by Matlab, but at least install the symbols for libxcb* and mesa.

Must be doing something wrong, I guess, as I do not see anything significant, but I see many warnings...


warning: Could not load shared library symbols for /tmp/jna--172125263/jna1816899428657434846.tmp.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185     ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
(gdb) bt full
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x00007fb83ab8504b in ?? () from /opt/MATLAB/R2016a/bin/glnxa64/libmwmcr.so
No symbol table info available.
#2  0x00007fb83ab86550 in ?? () from /opt/MATLAB/R2016a/bin/glnxa64/libmwmcr.so
No symbol table info available.
#3  0x00007fb83ab868f4 in mcr_run_main(boost::function0<int> const&, bool, bool) () from /opt/MATLAB/R2016a/bin/glnxa64/libmwmcr.so
No symbol table info available.
#4  0x00007fb83b1d3cad in ?? () from /opt/MATLAB/R2016a/bin/glnxa64/libmwMVMLocal.so
No symbol table info available.
#5  0x00007fb84b675777 in ?? () from /opt/MATLAB/R2016a/bin/glnxa64/libmwmvm.so
No symbol table info available.
#6  0x00007fb84b674fcc in ?? () from /opt/MATLAB/R2016a/bin/glnxa64/libmwmvm.so
No symbol table info available.
#7  0x00000000004059a1 in ?? ()
No symbol table info available.
#8  0x00007fb849788830 in __libc_start_main (main=0x4057c0, argc=1, argv=0x7fffad2a6c78, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffad2a6c68) at ../csu/libc-start.c:291
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -1402695454058173016, 4217724, 140736098626672, 0, 0, 1402806682128395688, 
                1438915041932783016}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x1, 0x4057c0}, data = {prev = 0x0, cleanup = 0x0, 
              canceltype = 1}}}
        not_first_call = <optimized out>
#9  0x0000000000405ba5 in ?? ()
No symbol table info available.
#10 0x00007fffad2a6c68 in ?? ()
No symbol table info available.
#11 0x000000000000001c in ?? ()
No symbol table info available.
#12 0x0000000000000001 in ?? ()
No symbol table info available.
#13 0x00007fffad2a7ddc in ?? ()
No symbol table info available.
#14 0x0000000000000000 in ?? ()
No symbol table info available.

Bah, threads. Makes the hunt more interesting. In gdb,

$ thread apply all bt full

Number of threads is very very large... anything that can be grepped?

(In reply to sergio.callegari from comment #6)
> Number of threads is very very large... anything that can be grepped?

It's better to see the whole output.  If the output is long, just add it as attachment instead of as comment.

Created attachment 127912 [details]
GDB full trace when MATLAB has hanged

I've also had this problem. I'm running Arch Linux with xf86-video-intel 1:2.99.917+725+gbf7316a-1, and MATLAB R2016a.

Output of glxinfo -B:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Ivybridge Mobile  (0x166)
    Version: 13.0.0
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.0
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 13.0.0
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 13.0.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00.

I've attached the output of a full GDB backtrace and it looks like you're right aboht the X11 mutex deadlock Chris.

I should add that, as mentioned elsewhere, setting LIBGL_DRI3_DISABLE=1 in the environment before starting MATLAB avoids all problems.

(In reply to f.mach4 from comment #8)
> Created attachment 127912 [details]
> GDB full trace when MATLAB has hanged

Ok, so everything is in pthread_cond_wait(), except couple of threads that:
* wait accepting network connection
* epoll_wait() or poll() from network connection

And then there's a lock wait on display close:
Thread 57 (Thread 0x7ffab9873700 (LWP 19273)):
#0  0x00007ffb75116f1c in __lll_lock_wait () at /usr/lib/libpthread.so.0
#1  0x00007ffb75110b45 in pthread_mutex_lock () at /usr/lib/libpthread.so.0
#2  0x00007ffb6990d083 in  () at /usr/lib/libX11.so.6
#3  0x00007ffb69902698 in XFreeGC () at /usr/lib/libX11.so.6
#4  0x00007ffb698fcb5c in XCloseDisplay () at /usr/lib/libX11.so.6
#5  0x00007ffab8c68042 in Java_jogamp_nativewindow_x11_X11Lib_XCloseDisplay(__complex) () at /opt/MATLAB/R2016a/bin/glnxa64/libnativewindow_x11.so

Which I assume is the deadlock preventing Matlab from exiting?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/105.