compiz crashed with SIGSEGV in std::_List_node_base::_M_hook()
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
unity (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: unity
Compiz (or parts of it) stop working on different occasions that are not fully reproducable to me. I was not able to provoke it on a freshly started session, it happens after 20 minutes or more.
Symptoms:
It can be that just the decorator on the second screen is removed, or also on the first. In this case the unity-panel is affected by not showing menu and window close/min/normal buttons. New windows don't get decorated.
It can get as far as not being able to select windows/widgets any more.
Most extrem is when the mouse is catched.
On one occasion I was not able to CTRL+ALT+F1 out of it.
Tried solutions:
I did not find a solution yet. "compiz-decorator --replace", "unity-
The only thing that helps is "killall gnome-session" - which loses all session data.
Nota bene: I am on a multi-monitor-
ProblemType: Crash
DistroRelease: Ubuntu 11.04
Package: unity 3.6.8-0ubuntu3
ProcVersionSign
Uname: Linux 2.6.38-7-generic i686
Architecture: i386
CrashCounter: 1
Date: Fri Mar 25 13:51:17 2011
ExecutablePath: /usr/bin/compiz
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
ProcCmdline: compiz
ProcEnviron:
LANGUAGE=de:en
LANG=de_DE.UTF-8
SHELL=/bin/bash
SegvAnalysis:
Segfault happened at: 0x9f30c7 <_ZNSt15_
PC (0x009f30c7) ok
source "%edx" ok
destination "(%ecx)" (0x00000002) not located in a known VMA region (needed writable region)!
SegvReason: writing NULL VMA
Signal: 11
SourcePackage: unity
StacktraceTop:
std::_
LauncherIcon:
?? () from /lib/i386-
g_main_
?? () from /lib/i386-
Title: compiz crashed with SIGSEGV in std::_List_
UpgradeStatus: Upgraded to natty on 2011-03-23 (2 days ago)
UserGroups: adm admin cdrom dialout dip fax floppy fuse lpadmin plugdev sambashare tape video
Hi, this bug should normally be fixed with 3.6.8, but your bug report may indicate that it is not.
However, could you detail the version of nux you're using, or more precisely were using while this problem happened? Nux also contains a refined GL detection logic that would have prevented this problem in the first place.