Bug 2169058

Summary: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Product: [Fedora] Fedora Reporter: Ali <akbaralivakhitov>
Component: glibAssignee: Paul Howarth <paul>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 37CC: mcatanza, paul, rdieter
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-02-11 15:28:47 UTC Type: Bug
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 Flags
log messages
none
security log messages
none
coredumpctl none

Description Ali 2023-02-11 13:40:01 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Ali 2023-02-11 14:12:28 UTC
Created attachment 1943521 [details]
log messages

Comment 2 Ali 2023-02-11 14:15:09 UTC
Created attachment 1943523 [details]
security log messages

Comment 3 Paul Howarth 2023-02-11 14:59:05 UTC
I don't see the assertion message in either of the log files.

Can you elaborate on what you were doing when this assertion was triggered? As it stands, I cannot even see which application this came from.

In any case, the assertion is almost certainly from either glib2 or glib3 since you probably don't even have the ancient glib package installed.

Comment 4 Michael Catanzaro 2023-02-11 15:28:47 UTC
Please provide a quality backtrace taken with G_DEBUG=fatal-criticals. Follow the instructions in https://blogs.gnome.org/mcatanzaro/2021/09/18/creating-quality-backtraces-for-crash-reports/.

I'm going to close this for now since we have no idea what component is to blame without a backtrace and it's not useful to keep  bugs open against the wrong component, but we can reopen if you provide a quality backtrace.

(P.S. glib3 doesn't exist. :)

Comment 5 Ali 2023-02-12 07:37:37 UTC
(In reply to Paul Howarth from comment #3)
> I don't see the assertion message in either of the log files.
> 
> Can you elaborate on what you were doing when this assertion was triggered?
> As it stands, I cannot even see which application this came from.
> To be honest, I am not quite sure, but I am getting this error in every single boot. The problem that I am actually having now is that I cannot wake my laptop up from suspend and sleep mode. It just keeps displaying the black screen
> In any case, the assertion is almost certainly from either glib2 or glib3
> since you probably don't even have the ancient glib package install(In reply to Paul Howarth from comment #3)
> I don't see the assertion message in either of the log files.
> 
> Can you elaborate on what you were doing when this assertion was triggered?
> As it stands, I cannot even see which application this came from.
> 
> In any case, the assertion is almost certainly from either glib2 or glib3
> since you probably don't even have the ancient glib package installed.

Comment 6 Ali 2023-02-12 08:58:50 UTC
Created attachment 1943664 [details]
coredumpctl

I do not understand why storage file is missing

Comment 7 Ali 2023-02-12 09:01:52 UTC
(In reply to Paul Howarth from comment #3)
I do not know exactly, but I am getting this in every single boot. The physical problem that is bothering me now is that I cannot wake my laptop up from suspend and sleep mode.

Comment 8 Ali 2023-02-12 09:04:24 UTC
(In reply to Michael Catanzaro from comment #4)
I tried to follow the instructions you gave. I posted an attachment but seems like the storage file is missing.

Comment 9 Michael Catanzaro 2023-02-12 13:32:00 UTC
Well if you don't have a functional coredumpctl, we cannot help you.

Also, your comment does not indicate that you set the G_DEBUG=fatal-criticals environment variable as requested, so there's no reason to expect a useful core dump there anyway. If it happens on boot and you have no idea what's causing it, you'll have to set the environment variable system-wide I guess. This will probably cause many more unrelated things to crash and likely you won't be able to boot successfully, but they'll all be real bugs worth reporting, so that's OK.