Description of problem:
Get this with latest rawhide:
[root@localhost ~]# python /usr/bin/sealert
***MEMORY-WARNING***: : 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...
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):
Steps to Reproduce:
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>
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,
AttributeError: 'ServerConnectionHandler' object has no attribute
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?
> 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.