Bug 2169058 - GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Summary: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: glib
Version: 37
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-02-11 13:40 UTC by Ali
Modified: 2023-02-12 13:32 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-02-11 15:28:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
log messages (5.11 KB, text/plain)
2023-02-11 14:12 UTC, Ali
no flags Details
security log messages (18.51 KB, text/plain)
2023-02-11 14:15 UTC, Ali
no flags Details
coredumpctl (16.77 KB, text/plain)
2023-02-12 08:58 UTC, Ali
no flags Details

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.


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