Bug 242064 - Glib issue: g_thread_init() must be called before all other GLib functions
Glib issue: g_thread_init() must be called before all other GLib functions
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: John Dennis
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-01 10:36 EDT by Tom London
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-20 22:12:35 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)
bugbuddy report of sealert crash (9.86 KB, text/plain)
2007-06-01 10:37 EDT, Tom London
no flags Details

  None (edit)
Description Tom London 2007-06-01 10:36:37 EDT
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:
Comment 1 Tom London 2007-06-01 10:37:44 EDT
Created attachment 155885 [details]
bugbuddy report of sealert crash
Comment 2 Deji Akingunola 2007-06-13 17:00:25 EDT
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'
<<
Comment 3 John Dennis 2007-06-13 23:33:11 EDT
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.
Comment 4 Deji Akingunola 2007-06-14 08:16:11 EDT
(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

Comment 5 Matthew Miller 2007-06-20 22:12:35 EDT
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.

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