Description of problem: Get this with latest rawhide: [root@localhost ~]# python /usr/bin/sealert ***MEMORY-WARNING***: [5107]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... [root@localhost ~]# Get crashes when I click on the 'star notifier'. [I've seen this error on other packages. Glib problem?] Version-Release number of selected component (if applicable): setroubleshoot-server-1.9.4-2.fc7 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 155885 [details] bugbuddy report of sealert crash
I got the following traceback, which seems to be related to the same bug after updating rawhide today (setroubleshoot-1.9.7-1.fc8); >> Opps, sealert hit an error! Traceback (most recent call last): File "/usr/bin/sealert", line 813, in <module> run_as_dbus_service(username) File "/usr/bin/sealert", line 147, in run_as_dbus_service app = SEAlert(username, dbus_service.presentation_manager) File "/usr/bin/sealert", line 540, in __init__ self.browser = BrowserApplet(self.username, self.alert_client) File "/usr/lib/python2.5/site-packages/setroubleshoot/browser.py", line 903, in __init__ self.update_connection_state(server.get_connection_state()) AttributeError: 'ServerConnectionHandler' object has no attribute 'get_connection_state' <<
Re: comment #2, sealert has a feature by which it detects when the daemon (setroublehootd) has been upgraded. The user is presented with a dialog box informing him of this and asking if he wants to restart sealert now. Did you get this error immediately after clicking yes to restart? After getting the error did you restart sealert (or logout and back in again) and it did start without the error? (or you could try to resart by hand with sealert -q to quit and sealert -s to start) The reason I'm asking is because the current working theory is setroubleshoot is broken into two packages with code interdependencis and we think they may be a race condition where only some of the python files have been updated before the restart occurs, but once installation of all the new files completes the problem cannot manifest itself again. Re: bug subject, we're thinking this is a glib issue, but will investigate.
(In reply to comment #3) > Re: comment #2, sealert has a feature by which it detects when the daemon > (setroublehootd) has been upgraded. The user is presented with a dialog box > informing him of this and asking if he wants to restart sealert now. Did you get > this error immediately after clicking yes to restart? Yes. > > After getting the error did you restart sealert (or logout and back in again) > and it did start without the error? (or you could try to resart by hand with > sealert -q to quit and sealert -s to start) I did as you outline above, and it's (still) running fine; though each invocation caused the bug subject warning. I haven't logged out since, but I ran /usr/bin/sealert after getting the error and got the glib's memory warning, which made me wrongfully think it didn't work
There's a bunch of similar bugs -- apparently the root problem is in glib2 itself. Therefore, these probably should all be closed as duplicates of bug #241925.