Nux

compiz crashed with SIGSEGV in nux::WindowThread::ComputeQueuedLayout()

Bug #1337244 reported by Margarita Manterola on 2014-07-03
68
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Nux
Fix Released
High
Erkin Bahceci
Trusty
Fix Committed
High
Erkin Bahceci
nux (Ubuntu)
High
Erkin Bahceci
Nominated for Trusty by Stephen M. Webb
Trusty
Undecided
Unassigned

Bug Description

[Impact]
Unity crashes when unlocking the session

[Test case 1]
1. Lock the session
2. Unlock the session
3. No crash should happen

[Test case 2]
1. Use unity in multi-monitor setup
2. Lock the session
3. Detach one of the monitors
4. Make sure the lockscreen updates (sometimes it's needed to switch to tty1 and back)
5. No crash should happen

[Regression potential]
None

Hi, this is basically the same bug as https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1298202, but that bug is marked as Fix Released with Unity 7.2.0, and I'm still seeing this bug on trusty, with the latest Unity version (unity 7.2.1+14.04.20140513-0ubuntu2). I already mentioned in that bug that I was still seeing it quite a while ago, but got no reply to that.

Crashes are being experienced in multiple machines, while unlocking the screen. The stacktraces vary, but they always fail in the same function and same line.

First stacktrace:
#0 0x0000000000000410 in ?? ()
#1 0x00007fd4bf4eb75d in nux::WindowThread::ComputeQueuedLayout (this=this@entry=0x22c1990) at ./WindowThread.cpp:318
#2 0x00007fd4bf4ecb28 in nux::WindowThread::RenderInterfaceFromForeignCmd (this=0x22c1990, clip=...) at ./WindowThread.cpp:1627
#3 0x00007fd4c0c20389 in unity::UnityScreen::paintDisplay() () from /usr/lib/compiz/libunityshell.so
#4 0x00007fd4c0c20748 in unity::UnityScreen::glPaintOutput(GLScreenPaintAttrib const&, GLMatrix const&, CompRegion const&, CompOutput*, unsigned int)
   () from /usr/lib/compiz/libunityshell.so
#5 0x00007fd4d4f2e272 in GLScreen::glPaintOutput(GLScreenPaintAttrib const&, GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
  from /usr/lib/compiz/libopengl.so
#6 0x00007fd4d4f2eed4 in PrivateGLScreen::paintOutputs(std::list<CompOutput*, std::allocator<CompOutput*> >&, unsigned int, CompRegion const&) ()
  from /usr/lib/compiz/libopengl.so
#7 0x00007fd4d556944f in CompositeScreen::paint(std::list<CompOutput*, std::allocator<CompOutput*> >&, unsigned int) ()
  from /usr/lib/compiz/libcomposite.so
#8 0x00007fd4d556caf2 in CompositeScreen::handlePaintTimeout() () from /usr/lib/compiz/libcomposite.so
#9 0x00007fd4e12c053d in CompTimer::triggerCallback() () from /usr/lib/libcompiz_core.so.ABI-20140123
#10 0x00007fd4e12c05ef in CompTimeoutSource::callback() () from /usr/lib/libcompiz_core.so.ABI-20140123
#11 0x00007fd4e12bfb4d in CompTimeoutSource::dispatch(sigc::slot_base*) () from /usr/lib/libcompiz_core.so.ABI-20140123
#12 0x00007fd4df7ac35f in Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*) () from /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#13 0x00007fd4df29ece5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007fd4df29f048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007fd4df29f30a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007fd4e127b0eb in compiz::private_screen::EventManager::startEventLoop(_XDisplay*) () from /usr/lib/libcompiz_core.so.ABI-20140123
#17 0x0000000000401971 in main ()

Second stacktrace (different machine):
#0 0x00007f0058407ed0 in nux_area_accessible_check_pending_notification () from /usr/lib/compiz/libunityshell.so
#1 0x00007f0056cb175d in nux::WindowThread::ComputeQueuedLayout (this=this@entry=0x1d530e0) at ./WindowThread.cpp:318
#2 0x00007f0056cb2b28 in nux::WindowThread::RenderInterfaceFromForeignCmd (this=0x1d530e0, clip=...) at ./WindowThread.cpp:1627
#3 0x00007f00583e6389 in unity::UnityScreen::paintDisplay() () from /usr/lib/compiz/libunityshell.so
#4 0x00007f00583e6748 in unity::UnityScreen::glPaintOutput(GLScreenPaintAttrib const&, GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) () from /usr/lib/compiz/libunityshell.so
#5 0x00007f00705e2272 in GLScreen::glPaintOutput(GLScreenPaintAttrib const&, GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
  from /usr/lib/compiz/libopengl.so
#6 0x00007f00705e2ed4 in PrivateGLScreen::paintOutputs(std::list<CompOutput*, std::allocator<CompOutput*> >&, unsigned int, CompRegion const&) ()
  from /usr/lib/compiz/libopengl.so
#7 0x00007f0070c1d44f in CompositeScreen::paint(std::list<CompOutput*, std::allocator<CompOutput*> >&, unsigned int) ()
  from /usr/lib/compiz/libcomposite.so
#8 0x00007f0070c20af2 in CompositeScreen::handlePaintTimeout() () from /usr/lib/compiz/libcomposite.so
#9 0x00007f007879b53d in CompTimer::triggerCallback() () from /usr/lib/libcompiz_core.so.ABI-20140123
#10 0x00007f007879b5ef in CompTimeoutSource::callback() () from /usr/lib/libcompiz_core.so.ABI-20140123
#11 0x00007f007879ab4d in CompTimeoutSource::dispatch(sigc::slot_base*) () from /usr/lib/libcompiz_core.so.ABI-20140123
#12 0x00007f0076c8735f in Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*) () from /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#13 0x00007f0076779ce5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f007677a048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f007677a30a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007f00787560eb in compiz::private_screen::EventManager::startEventLoop(_XDisplay*) () from /usr/lib/libcompiz_core.so.ABI-20140123
#17 0x0000000000401971 in main ()

I have more, but I don't know how useful it is to add them all.

All stacktraces have this as #1:
#1 0x00007fd4bf4eb75d in nux::WindowThread::ComputeQueuedLayout (this=this@entry=0x22c1990) at ./WindowThread.cpp:318

This is the affected code:

void WindowThread::ComputeQueuedLayout()
 {
   StartLayoutCycle();
   std::list<Area *>::iterator it;

   for (it = _queued_layout_list.begin(); it != _queued_layout_list.end(); ++it)
   {
     Area *area = *it;

     if (area->Type().IsDerivedFromType(View::StaticObjectType))

The last line is 318.

I expect there is some item in the _queued_layout_list that is getting corrupted.

Related branches

Margarita Manterola (marga-9) wrote :

This keeps happening over and over. Looking at the resolution of the other bug, I expect the code that needs to be fixed is not here, but in the handling of some element in this queue. I suspect some element is getting deleted and the memory reused without it being removed from the queue.

Here's the latest stacktrace:
#0 0x0000000000000000 in ?? ()
#1 0x00007fdd0a32c75d in nux::WindowThread::ComputeQueuedLayout (this=this@entry=0x2319f40) at ./WindowThread.cpp:318
#2 0x00007fdd0a32db28 in nux::WindowThread::RenderInterfaceFromForeignCmd (this=0x2319f40, clip=...) at ./WindowThread.cpp:1627
#3 0x00007fdd0ba61389 in unity::UnityScreen::paintDisplay() () from /usr/lib/compiz/libunityshell.so
#4 0x00007fdd0ba61748 in unity::UnityScreen::glPaintOutput(GLScreenPaintAttrib const&, GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) () from /usr/lib/compiz/libunityshell.so
#5 0x00007fdd1b3da272 in GLScreen::glPaintOutput(GLScreenPaintAttrib const&, GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
  from /usr/lib/compiz/libopengl.so
#6 0x00007fdd1b3daed4 in PrivateGLScreen::paintOutputs(std::list<CompOutput*, std::allocator<CompOutput*> >&, unsigned int, CompRegion const&) ()
  from /usr/lib/compiz/libopengl.so
#7 0x00007fdd203e144f in CompositeScreen::paint(std::list<CompOutput*, std::allocator<CompOutput*> >&, unsigned int) ()
  from /usr/lib/compiz/libcomposite.so
#8 0x00007fdd203e4af2 in CompositeScreen::handlePaintTimeout() () from /usr/lib/compiz/libcomposite.so
#9 0x00007fdd2cc6b53d in CompTimer::triggerCallback() () from /usr/lib/libcompiz_core.so.ABI-20140123
#10 0x00007fdd2cc6b5ef in CompTimeoutSource::callback() () from /usr/lib/libcompiz_core.so.ABI-20140123
#11 0x00007fdd2cc6ab4d in CompTimeoutSource::dispatch(sigc::slot_base*) () from /usr/lib/libcompiz_core.so.ABI-20140123
#12 0x00007fdd2b15735f in Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*) () from /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#13 0x00007fdd2ac49ce5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007fdd2ac4a048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007fdd2ac4a30a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007fdd2cc260eb in compiz::private_screen::EventManager::startEventLoop(_XDisplay*) () from /usr/lib/libcompiz_core.so.ABI-20140123
#17 0x0000000000401971 in main ()

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in unity (Ubuntu):
status: New → Confirmed
Changed in unity:
status: New → Confirmed
Erkin Bahceci (cornelius1) wrote :

It seems like FloatingWindow is being added to the queue with QueueObjectLayout in FloatingWindow.cpp, but might not be removed from the queue before it's deleted. Its ancestor Area has the same potential issue, as well. So, moving the RemoveObjectFromLayoutQueue call in View and Layout destructors to their common ancestor Area's destructor (as in the attached patch) should fix that issue (and this bug, unless something else is overwriting the objects in that queue).

The attachment "nux-remove-area-from-layout-queue.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Erkin Bahceci (cornelius1) wrote :

Actually, since View is FloatingWindow's indirect base class, and since InputArea (which is the only other class derived from Area besides Layout) is a direct base class of View, and InputArea objects are not put on that queue, the RemoveObjectFromLayoutQueue calls in View and Layout destructors do seem to remove all queued Area objects (including FloatingWindow objects). So, the patch wouldn't fix the bug, so I've removed it.

Erkin Bahceci (cornelius1) wrote :

However, if the "parent object of an object of type InputArea is a Layout object" comment at Area.cpp:603 is inaccurate (as some of the other comments there, such as the ones at :540, :576, and :596), and if InputArea objects can have HSplitter or VSplitter as parent, then they could be added to the queue at Area.cpp:521, in which case they would need to be removed from the queue in the InputArea destructor (as in the attached patch).

Erkin Bahceci (cornelius1) wrote :

And since InputArea and Layout are the only classes derived directly from Area, and they would both have the same code in their destructors with the patch in #6, the removal code can be moved to the Area destructor, as in the attached patch.

Erkin Bahceci (cornelius1) wrote :

Though, the Unity code doesn't seem to use HSplitter or VSplitter. Also, it doesn't call QueueRelayout on any InputArea objects, which seems to be the only other way for an InputArea object to be put on the layout queue. Btw the "parent object of an object of type InputArea is a Layout object" comment at Area.cpp:603 is indeed wrong, since UnityWindowView::GetBoundingArea() has a counterexample.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nux (Ubuntu):
status: New → Confirmed
Changed in nux:
status: New → In Progress
importance: Undecided → High
milestone: none → 4.0.7
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
Changed in unity:
status: Confirmed → Won't Fix
Changed in unity (Ubuntu):
status: Confirmed → Won't Fix
no longer affects: unity
no longer affects: unity (Ubuntu)
Changed in nux (Ubuntu):
status: Confirmed → In Progress
importance: Undecided → High
Changed in nux:
assignee: Marco Trevisan (Treviño) (3v1n0) → Erkin Bahceci (cornelius1)
Changed in nux (Ubuntu):
assignee: nobody → Erkin Bahceci (cornelius1)
description: updated
Changed in nux (Ubuntu Trusty):
status: New → Confirmed
Alexei (lxmzhv) wrote :

A highly visible and very annoying bug! Would be great to have it fixed.

Hello Margarita, or anyone else affected,

Accepted nux into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/nux/4.0.6+14.04.20140930-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nux (Ubuntu Trusty):
status: Confirmed → Fix Committed
tags: added: verification-needed
Changed in nux:
status: In Progress → Fix Committed
description: updated
tags: added: verification-done
removed: verification-needed
Changed in nux (Ubuntu):
status: In Progress → Fix Released

The verification of the Stable Release Update for nux has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nux - 4.0.6+14.04.20140930-0ubuntu1

---------------
nux (4.0.6+14.04.20140930-0ubuntu1) trusty; urgency=low

  [ Erkin Bahceci ]
  * Area: always make sure we remove and object from layout queue. (LP:
    #1337244)

  [ Marco Trevisan (Treviño) ]
  * ScrollView: correctly handle vertical and horizontal scrolling. (LP:
    #1228093)
 -- Ubuntu daily release <email address hidden> Tue, 30 Sep 2014 16:05:28 +0000

Changed in nux (Ubuntu Trusty):
status: Fix Committed → Fix Released
Stephen M. Webb (bregma) on 2015-08-12
Changed in nux:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers