Bug#754392: libc6:amd64: lock elision code used on machine not supporting TSX (xbegin, ...) instructions
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?
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: