Bug 444688 - compiz segfaults on shutdown
compiz segfaults on shutdown
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: compiz (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Kristian Høgsberg
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-29 22:51 EDT by Tom London
Modified: 2009-07-14 14:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 14:08:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log when compiz crashed at shutdown (43.16 KB, text/plain)
2008-04-29 22:51 EDT, Tom London
no flags Details

  None (edit)
Description Tom London 2008-04-29 22:51:56 EDT
Description of problem:
I noticed this in /var/log/messages:

Apr 29 17:52:44 localhost init: tty1 main process (2672) killed by TERM signal
Apr 29 17:52:44 localhost init: tty6 main process (2673) killed by TERM signal
Apr 29 17:52:44 localhost gconfd (tbl-2953): Exiting
Apr 29 17:52:44 localhost kernel: printk: 1 messages suppressed.
Apr 29 17:52:44 localhost kernel: compiz[3166]: segfault at 3b66 ip 0805482c sp
bfc04830 error 4 in compiz[8048000+36000]
Apr 29 17:52:47 localhost smartd[2664]: smartd received signal 15: Terminated
Apr 29 17:52:47 localhost smartd[2664]: smartd is exiting (exit status 0)
Apr 29 17:52:48 localhost audio-entropyd: audio-entropyd stopping due to signal 15

and an earlier (appears similar) one:

Apr 28 17:38:08 localhost init: tty1 main process (2687) killed by TERM signal
Apr 28 17:38:08 localhost init: tty6 main process (2688) killed by TERM signal
Apr 28 17:38:08 localhost gconfd (tbl-2988): Exiting
Apr 28 17:38:09 localhost kernel: printk: 1 messages suppressed.
Apr 28 17:38:09 localhost kernel: compiz[3203]: segfault at 20 ip 0805481d sp
bff92bc0 error 4 in compiz[8048000+36000]
Apr 28 17:38:10 localhost smartd[2669]: smartd received signal 15: Terminated
Apr 28 17:38:10 localhost smartd[2669]: smartd is exiting (exit status 0)

Not sure how to provide additional info.....

No other obvious messages in /var/log/messages or in /var/log/Xorg.0.log (one
attached).

I am running on Thinkpad X60 (Intel 945).

I start compiz with:

LIBGL_ALWAYS_INDIRECT=1 compiz --indirect-rendering --replace ccp || metacity
--replace



Version-Release number of selected component (if applicable):
compiz-fusion-extras-0.7.2-2.fc9.i386
compiz-gnome-0.7.2-3.fc9.i386
compiz-fusion-gnome-0.7.2-2.fc9.i386
xorg-x11-server-utils-7.3-3.fc9.i386
compizconfig-python-0.7.2-1.fc9.i386
compiz-manager-0.6.0-7.fc9.noarch
compiz-fusion-extras-gnome-0.7.2-2.fc9.i386
compiz-0.7.2-3.fc9.i386
compiz-fusion-0.7.2-2.fc9.i386
compizconfig-backend-gconf-0.7.2-1.fc9.i386
xorg-x11-drv-i810-2.2.1-22.fc9.i386
xorg-x11-server-common-1.4.99.901-26.20080415.fc9.i386
xorg-x11-server-Xorg-1.4.99.901-26.20080415.fc9.i386

How reproducible:
Does not seem to happen every time.

Steps to Reproduce:
1. Shutdown?
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Tom London 2008-04-29 22:51:56 EDT
Created attachment 304170 [details]
Xorg.0.log when compiz crashed at shutdown
Comment 2 Tom London 2008-04-30 18:29:56 EDT
Got another one today:

Apr 30 07:56:44 localhost NetworkManager: <info>  Bringing down device wlan0
Apr 30 07:56:45 localhost acpid: exiting
Apr 30 07:56:46 localhost nm-system-settings: disconnected by the system bus.
Apr 30 07:56:46 localhost console-kit-daemon[2163]: GLib-CRITICAL:
g_async_queue_unref: assertion `queue->waiting_threads == 0' failed
Apr 30 07:56:46 localhost gnome-keyring-daemon[2934]: Scheduling hal init retry
Apr 30 07:56:47 localhost kernel: printk: 1 messages suppressed.
Apr 30 07:56:47 localhost kernel: compiz[3147]: segfault at 648 ip 0805482c sp
bff67b90 error 4 in compiz[8048000+36000]
Apr 30 07:56:47 localhost console-kit-daemon[2163]: GLib-CRITICAL:
g_async_queue_push: assertion `g_atomic_int_get (&queue->ref_count) > 0' failed
Apr 30 07:56:47 localhost console-kit-daemon[2163]: GLib-CRITICAL:
g_async_queue_lock: assertion `g_atomic_int_get (&queue->ref_count) > 0' failed
Apr 30 07:56:47 localhost console-kit-daemon[2163]: GLib-CRITICAL:
g_async_queue_length_unlocked: assertion `g_atomic_int_get (&queue->ref_count) >
0' failed
Apr 30 07:56:47 localhost restorecond: terminated
Comment 3 Tom London 2008-05-01 10:54:20 EDT
Another one this morning:

May  1 06:27:14 localhost acpid: exiting
May  1 06:27:16 localhost console-kit-daemon[2157]: GLib-CRITICAL:
g_async_queue_unref: assertion `queue->waiting_threads == 0' failed
May  1 06:27:16 localhost nm-system-settings: disconnected by the system bus.
May  1 06:27:16 localhost kernel: compiz[3133]: segfault at 42b03c1 ip 0805481d
sp bf9f4620 error 4 in compiz[8048000+36000]
May  1 06:27:16 localhost gnome-keyring-daemon[2932]: Scheduling hal init retry
May  1 06:27:17 localhost restorecond: terminated


Is there some way to collect additional details....?
Comment 4 Tom London 2008-05-01 10:55:31 EDT
I guess a question would be why would compiz still be running this late during
shutdown?

Comment 5 Tom London 2008-05-03 12:51:08 EDT
Got a slightly different scenario this time, but still looks like shutdown.

Not sure its helpful, but I installed 'compiz-debuginfo' after this.

May  2 16:33:37 localhost init: tty3 main process (2711) killed by TERM signal
May  2 16:33:37 localhost init: tty1 main process (2712) killed by TERM signal
May  2 16:33:37 localhost gdm-session-worker[30043]: DEBUG: GdmSignalHandler:
handling signal 15
May  2 16:33:37 localhost init: tty6 main process (2713) killed by TERM signal
May  2 16:33:37 localhost gdm-session-worker[30043]: DEBUG: GdmSignalHandler:
Found 1 callbacks
May  2 16:33:37 localhost gdm-session-worker[30043]: DEBUG: GdmSignalHandler:
running 15 handler: 0x804b1b0
May  2 16:33:37 localhost gdm-session-worker[30043]: DEBUG: Got callback for
signal 15
May  2 16:33:37 localhost gdm-session-worker[30043]: DEBUG: Caught signal 15,
shutting down normally.
May  2 16:33:37 localhost gdm-session-worker[30043]: DEBUG: GdmSignalHandler:
Caught termination signal - exiting main loop
May  2 16:33:37 localhost gdm-session-worker[30043]: DEBUG: GdmSignalHandler:
Finalizing signal handler
May  2 16:33:37 localhost gdm-session-worker[30043]: DEBUG: Worker finished
May  2 16:33:37 localhost gconfd (tbl-30129): Exiting
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: Writing logout record
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: using ut_type DEAD_PROCESS
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: using ut_tv time
1209771217
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: using ut_pid 30136
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: using ut_id :0
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: using ut_host :0
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: using ut_line tty7
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: Writing wtmp logout
record to /var/log/wtmp
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: Removing utmp record
May  2 16:33:37 localhost kernel: compiz[30329]: segfault at 6c6576 ip 0805481d
sp bff02330 error 4 in compiz[8048000+36000]
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: GdmSessionWorkerJob:
Stopping job pid:30043
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: GdmCommon: sending
signal 15 to process 30043
May  2 16:33:37 localhost gdm-simple-slave[29963]: DEBUG: GdmSessionWorkerJob:
Waiting on process 30043
Comment 6 Tom London 2008-05-03 16:42:44 EDT
I got this one:

May  3 13:30:31 localhost kernel: compiz[3130]: segfault at 3f800000 ip 0805482c
sp bfeda310 error 4 in compiz[8048000+36000]

But this time I managed to "save" ~/.xsession-errors from that session.  Here is
what it says during the shutdown.  Can this all be related?

** (gnome-panel:3117): WARNING **: Failed to establish a connection with GDM: No
such file or directory
gnome-session: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.
gnome-panel: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Pidgin 2.4.1-2.fc9 has segfaulted and attempted to dump a core file.
This is a bug in the software and has happened through
no fault of your own.

If you can reproduce the crash, please notify the developers
by reporting a bug at:
http://developer.pidgin.im/simpleticket/

Please make sure to specify what you were doing at the time
and post the backtrace from the core file.  If you do not know
how to get the backtrace, please read the instructions at
http://developer.pidgin.im/wiki/GetABacktrace

If you need further assistance, please IM either SeanEgn or 
LSchiere (via AIM).  Contact information for Sean and Luke 
on other protocols is at
http://developer.pidgin.im/wiki/DeveloperPages
nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
gnome-terminal: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.
gtk-window-decorator: Fatal IO error 11 (Resource temporarily unavailable) on X
server :0.0.
pam-panel-icon: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.

(gnome-panel:3117): GLib-GObject-CRITICAL **: g_object_run_dispose: assertion
`G_IS_OBJECT (object)' failed

(gnome-panel:3117): GLib-GObject-CRITICAL **: g_object_run_dispose: assertion
`G_IS_OBJECT (object)' failed
Comment 7 Tom London 2008-05-10 12:40:42 EDT
Continue to get segfaults with logs in .xession-errors similar to above on most
shutdowns.

I don't see any functional issues, however.
Comment 8 Bug Zapper 2008-05-14 06:24:40 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Bug Zapper 2009-06-09 20:31:36 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2009-07-14 14:08:17 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.