After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 563872 - g_object_unref assert in debug code
g_object_unref assert in debug code
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gobject
unspecified
Other All
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
: 758359 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-12-09 16:15 UTC by Morten Welinder
Modified: 2018-05-24 11:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Morten Welinder 2008-12-09 16:15:20 UTC
It would be useful if the assert in g_object_unref was changed to
something like...

    gboolean ok;
    /* catch objects not chaining finalize handlers */
    G_LOCK (debug_objects);
    ok = (g_hash_table_lookup (debug_objects_ht, object) == NULL);
    G_UNLOCK (debug_objects);
    if (!ok) {
         g_warning ("Object %p of type %s not finalized correctly.",
                    object, G_OBJECT_TYPE_NAME (object));
         g_hash_table_remove (debug_objects_ht, object);
    }

i.e., something non-critical.  The program can go on just fine and tell
me about other problems.  (And people should run this occasionally,
see bug 563803.)
Comment 1 Philip Withnall 2017-11-17 11:52:16 UTC
I disagree. If it’s changed to a warning, people will ignore it, and logs will fill up with these unnoticed warnings. It’s a programmer error, so an assertion failure is the right way to deal with it.

If you want to skip over it in a debugger, you can use gdb’s `continue` command after a g_assert() failure to continue program execution.
Comment 2 Morten Welinder 2017-11-17 13:06:56 UTC
I don't think you looked at the code.

> If it’s changed to a warning, people will ignore it,
> and logs will fill up with these unnoticed warnings.

No.  The only people who get the warning in the first place are people who
specifically compile with G_ENABLE_DEBUG *and* turn object warnings on with
a GOBJECT_DEBUG=objects setting.  So no filled-up logs.

> It’s a programmer error, so an assertion failure is the right way
> to deal with it.

Gtk+ has thousands of g_return_{val_,}if_fail invocations, each checking for
a programmer error.  You seem to be arguing that those should be asserts.

> If you want to skip over it in a debugger, you can use gdb’s `continue`
> command after a g_assert() failure to continue program execution.

No, you can't.  Go ahead -- toss a g_assert(0==1) into a random program
and try it.  Once you hit that, you are not going any further.

g_assert works by calling abort() which in turn works by sending the
ABRT signal.  You could tell gdb to ignore that

    handle SIGABRT nopass noprint nostop

but then abort just triggers a segfault in a loop.
Comment 3 Philip Withnall 2017-11-17 14:29:54 UTC
*** Bug 758359 has been marked as a duplicate of this bug. ***
Comment 4 Philip Withnall 2017-11-17 14:40:40 UTC
(In reply to Morten Welinder from comment #2)
> I don't think you looked at the code.

Not in great detail, no. I’m triaging a lot of bugs and not spending a lot of time on each of them, and relying on people to re-open them if my triage is wrong. Thanks for doing that.

> > If it’s changed to a warning, people will ignore it,
> > and logs will fill up with these unnoticed warnings.
> 
> No.  The only people who get the warning in the first place are people who
> specifically compile with G_ENABLE_DEBUG *and* turn object warnings on with
> a GOBJECT_DEBUG=objects setting.  So no filled-up logs.

OK. I think warnings are still hard to act on, since they get mixed in with other output, and if you want to get any of the program context at the time of the warning, you need to run in a debugger (with G_DEBUG=fatal-warnings) anyway.

> > It’s a programmer error, so an assertion failure is the right way
> > to deal with it.
> 
> Gtk+ has thousands of g_return_{val_,}if_fail invocations, each checking for
> a programmer error.  You seem to be arguing that those should be asserts.

A g_return_if_fail() would be better here, indeed. g_assert() should really be reserved for checking internal state (which isn’t subject to change based on third-party code).

Would you be in favour of changing the g_assert() to a g_return_if_fail(), or a g_critical() if we want a more customised error message?

> > If you want to skip over it in a debugger, you can use gdb’s `continue`
> > command after a g_assert() failure to continue program execution.
> 
> No, you can't.

My mistake.
Comment 5 GNOME Infrastructure Team 2018-05-24 11:39:45 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/179.