Bug 72845 - Weston SEGV or SIGILL while hot-unplug output with actively rendering client
Summary: Weston SEGV or SIGILL while hot-unplug output with actively rendering client
Status: VERIFIED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium critical
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-18 20:52 UTC by U. Artie Eoff
Modified: 2014-01-07 20:33 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
gdb backtrace, segv 1 (12.06 KB, text/plain)
2013-12-18 20:52 UTC, U. Artie Eoff
Details
gdb illegal instruction backtrace (10.57 KB, text/plain)
2013-12-18 20:53 UTC, U. Artie Eoff
Details

Description U. Artie Eoff 2013-12-18 20:52:30 UTC
Created attachment 90946 [details]
gdb backtrace, segv 1

Weston segfaults in the bowels of the EGL when unplugging an output while that output has an actively rendering client application present.  I am able to reproduce this about 95% of the time on my first try with weston-terminal.  With weston-terminal, running a command that generates a lot of output will trigger this easier (e.g. "ls -alR /")

1. Two cold-plugged displays
2. Launch weston
3. Launch weston-terminal and maximize it onto the primary (left) display.
4. Run the following command in the weston-terminal 'ls -alR /'
5. Unplug the primary display (the one with weston-terminal on it)
6. Observe weston-terminal moves to secondary (right) display and secondary display becomes the primary display.
7. Plug in the original primary display
8. Observe the hotplugged display now becomes secondary display (right).
9. Move weston-terminal back to the original display
10. Execute 'ls -alR /' in the weston-terminal again.
11. Unplug secondary display (the one with weston-terminal on it)
12. Observe Weston segmentation fault
Comment 1 U. Artie Eoff 2013-12-18 20:53:15 UTC
Created attachment 90947 [details]
gdb illegal instruction backtrace
Comment 2 U. Artie Eoff 2013-12-18 20:54:13 UTC
Illegal instruction
Comment 3 U. Artie Eoff 2013-12-18 20:55:00 UTC
kernel 3.11.10-301.fc20.x86_64
systemd (master) heads/master-0-g63966da
wayland (master) 1.3.91-0-g01bde63
drm (master) libdrm-2.4.50-0-g4c5de72
mesa (master) heads/master-0-ga9bf599
libva (master) libva-1.2.1-0-g88ed1eb
intel-driver (master) 1.2.1-0-g8f306e3
weston (master) heads/master-0-gdf42a80
Comment 4 Ander Conselvan de Oliveira 2013-12-19 15:09:22 UTC
What CPU did you run this in? The backtrace shows the illegal instruction happens in __lll_lock_elision(), now I'm wondering if lock elision was being used in a CPU that does not support it.
Comment 5 U. Artie Eoff 2013-12-19 15:12:26 UTC
(In reply to comment #4)
> What CPU did you run this in? The backtrace shows the illegal instruction
> happens in __lll_lock_elision(), now I'm wondering if lock elision was being
> used in a CPU that does not support it.

I observed this on an NDiS 166... which has a Sandybridge (Celeron series I believe)
Comment 6 Ander Conselvan de Oliveira 2013-12-19 16:37:16 UTC
Or this could be a stale pointer causing lock data to become corrupt. I submitted a patch to the mailing list that may or may not have something do with this bug.

http://lists.freedesktop.org/archives/wayland-devel/2013-December/012651.html
Comment 7 Kristian Høgsberg 2013-12-20 06:53:56 UTC
commit 24dff2b704a1cbf70b2785561934b83486c7f8fb
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Thu Dec 19 18:34:28 2013 +0200

    compositor: Clean up view output move and destroy listeners
    
    Remove those listeners when the output is destroyed, otherwise they'll
    point to invalid data that may lead to corruption when assigning a new
    output for the view.
    
    --
    This is possibly related to bug 72845. I didn't have enough equipment
    to try and reproduce it.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=72845


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.