Bug 242064
| Summary: | Glib issue: g_thread_init() must be called before all other GLib functions | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom London <selinux> | ||||
| Component: | setroubleshoot | Assignee: | John Dennis <jdennis> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | rawhide | CC: | dakingun | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-06-21 02:12:35 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Tom London
2007-06-01 14:36:37 UTC
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. |