On 12/07/14 21:29, Aurelien Jarno wrote: > reassign 754392 weston/1.5.0-2 > retitle 754392 weston: segfault on exit when cms-colord.so is loaded > forwarded 754392 https://bugs.freedesktop.org/show_bug.cgi?id=79560 > thanks > > On Thu, Jul 10, 2014 at 09:03:34PM +0200, Aurelien Jarno wrote: >> On Thu, Jul 10, 2014 at 04:52:42PM +0200, Laurent Bigonville wrote: >>> Package: libc6 >>> Version: 2.19-5 >>> Severity: serious >>> >>> Hi, >>> >>> On my amd64 machine, weston is crashing on exit with an illegal >>> instruction when the colord plugin is loaded. >>> >>> Using gdb shows me the following backtrace: >>> >>> #0 0x00007ffff681d18b in _xbegin () at >>> ../nptl/sysdeps/unix/sysv/linux/x86/hle.h:53 >>> #1 __lll_lock_elision (futex=0x727ab0, adapt_count=0x727ac6, private=128) >>> at ../nptl/sysdeps/unix/sysv/linux/x86/elision-lock.c:56 >>> #2 0x00007fffeca9d991 in g_mutex_lock (mutex=<optimized out>) at >>> /tmp/buildd/glib2.0-2.40.0/./glib/gthread-posix.c:209 >>> #3 0x00007fffed732e5f in colord_idle_cancel_for_output >>> (cms=0x7fffe0003050, o=0x6dbca0) at src/cms-colord.c:77 >>> #4 0x00007fffed7333bf in colord_notifier_output_destroy >>> (listener=0x7fffe00030a8, data=0x6dbca0) at src/cms-colord.c:223 >>> #5 0x0000000000407673 in wl_signal_emit (signal=0x6dbeb0, data=0x6dbca0) >>> at /usr/include/wayland-server.h:260 >>> #6 0x000000000040e9a3 in weston_output_destroy (output=0x6dbca0) at >>> src/compositor.c:3119 >>> #7 0x00007ffff6600b23 in x11_output_destroy (output_base=0x6dbca0) at >>> src/compositor-x11.c:497 >>> #8 0x00007ffff6601c72 in x11_compositor_delete_window (c=0x6400c0, >>> window=50331653) at src/compositor-x11.c:935 >>> #9 0x00007ffff66027a2 in x11_compositor_handle_event (fd=10, mask=1, >>> data=0x6400c0) at src/compositor-x11.c:1273 >>> #10 0x00007ffff7bd3c22 in wl_event_loop_dispatch (loop=0x641290, >>> timeout=<optimized out>) at ../src/event-loop.c:419 >>> #11 0x000000000040c164 in weston_compositor_read_input (fd=9, mask=1, >>> data=0x6400c0) at src/compositor.c:1830 >>> #12 0x00007ffff7bd3c22 in wl_event_loop_dispatch (loop=0x630240, >>> timeout=timeout@entry=-1) at ../src/event-loop.c:419 >>> #13 0x00007ffff7bd2265 in wl_display_run (display=0x6301b0) at >>> ../src/wayland-server.c:969 >>> #14 0x000000000041116f in main (argc=1, argv=0x7fffffffe138) at >>> src/compositor.c:4316 >>> >>> >>> This is the (illegal) instruction executed: >>> => 0x7ffff681d18b <__lll_lock_elision+75>: xbeginq 0x7ffff681d191 >>> <__lll_lock_elision+81> >>> >>> These instruction are only available on Haswell+ CPU's >>> >> >> Do you also have problems with other programs than Weston? I really >> doubt this is a bug in the libc. For me it looks like the memory holding >> the mutex has been corrupted, forcing the PTHREAD_MUTEX_ELISION_NP flag. >> Unfortunately it's not easy to check as the mutex variable is not >> accessible in gdb due do the code optimization. >> >> However the only code path in the glibc which can enable this flag is >> executed conditionally when the __pthread_force_elision variable is set. >> Could you please therefore run "print __pthread_force_elision" in gdb >> after getting the backtrace? > > I have been able to reproduce the problem, and I confirmed that > __pthread_force_elision is set to 0. Also the problem is an illegal > instruction only part of the time, other times I also got this following > error: > > | GLib (gthread-posix.c): Unexpected error from C library during > 'pthread_mutex_lock': Invalid argument. Aborting. > | [21:01:32.483] caught signal: 6 > | [21:01:32.483] [000000000040814a] -- (weston) > | [21:01:32.483] [00000000004081b7] -- (weston) > | [21:01:32.483] [00007ff4a4c98480] -- (/lib/x86_64-linux-gnu/libc.so.6) > | [21:01:32.483] [00007ff4a4c98407] gsignal > (/lib/x86_64-linux-gnu/libc.so.6) > | [21:01:32.484] [00007ff4a4c997e8] abort > (/lib/x86_64-linux-gnu/libc.so.6) > | [21:01:32.484] [00007ff49a2d9453] -- > (/lib/x86_64-linux-gnu/libglib-2.0.so.0) > | [21:01:32.484] [00007ff49a3489a3] g_mutex_lock > (/lib/x86_64-linux-gnu/libglib-2.0.so.0) > | [21:01:32.484] [00007ff49afddf15] -- > (/usr/lib/x86_64-linux-gnu/weston/cms-colord.so) > | [21:01:32.484] [00007ff49afde750] -- > (/usr/lib/x86_64-linux-gnu/weston/cms-colord.so) > | [21:01:32.484] [000000000040dc54] weston_output_destroy (weston) > | [21:01:32.484] [00007ff4a442d1fa] -- > (/usr/lib/x86_64-linux-gnu/weston/x11-backend.so) > | [21:01:32.484] [00007ff4a442d674] -- > (/usr/lib/x86_64-linux-gnu/weston/x11-backend.so) > | [21:01:32.484] [00007ff4a59fdc22] wl_event_loop_dispatch > (/usr/lib/x86_64-linux-gnu/libwayland-server.so.0) > | [21:01:32.484] [0000000000408d32] -- (weston) > | [21:01:32.484] [00007ff4a59fdc22] wl_event_loop_dispatch > (/usr/lib/x86_64-linux-gnu/libwayland-server.so.0) > | [21:01:32.484] [00007ff4a59fc265] wl_display_run > (/usr/lib/x86_64-linux-gnu/libwayland-server.so.0) > | [21:01:32.484] [000000000040785c] -- (weston) > | [21:01:32.484] [00007ff4a4c84b45] __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6) > | [21:01:32.484] [0000000000407a35] -- (weston) > > This clearly show that the memory corresponding to the mutex passed to > pthread_mutex_lock is corrupted. Some of the time the lock elision flag > is set, causing the illegal instruction you observed.
Any chance debugging this? Have you tried with valgrind? Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
