Bug 173907 – REGRESSION(r218799): [GTK][WPE] Critical warning at exit

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[Carlos Garcia Campos]

GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

This is now always happening when closing the MeiniBrowser and it's causing a lot of unit tests to fail. In r218799, GRefPtrGtk.h include was removed from PasteboardHelper.h that contains a GRefPtr<GtkTargetList>. The targets are destroyed at exit, but now trying to use g_object_unref instead of gtk_target_list_unref(). I've found two more cases like this in r218799, that removes GUniquePtrSoup.h from ResourceHandleInternal.h and ResourceRequest.h that have GUniquePtr<SoupBuffer> and GUniquePtr<SoupURI>. WE need to be very careful when removing GRefPtrGtk.h, RefPtrCairo.h, CairoUniquePtr.h, GRefPtrSoup.h, GUniquePtrSoup.h, GRefPtrGStreamer.h and GUniquePtrGStreamer.h. I'll check other commits removing headers, because this can lead to pretty weird bugs that are not that easy to find.

[Carlos Garcia Campos]

Created attachment 313998 [details]
Patch

[Konstantin Tokarev]

Oops, my bad.

Source/WebCore/platform/graphics/gstreamer/InbandMetadataTextTrackPrivateGStreamer.h should have #include "GRefPtrGStreamer.h"

Source/WebCore/platform/gtk/ScrollbarThemeGtk.h - #include <wtf/glib/GRefPtr.h>

I didn't find any other cases

[Carlos Garcia Campos]

(In reply to Konstantin Tokarev from comment #2)
> Oops, my bad.
> 
> Source/WebCore/platform/graphics/gstreamer/
> InbandMetadataTextTrackPrivateGStreamer.h should have #include
> "GRefPtrGStreamer.h"
> 
> Source/WebCore/platform/gtk/ScrollbarThemeGtk.h - #include
> <wtf/glib/GRefPtr.h>
> 
> I didn't find any other cases

Those are not a problem because they don't use GRefPtr at all, I guess they did at some point and the header was never removed.

[Carlos Garcia Campos]

Committed r218870: <http://trac.webkit.org/changeset/218870>

[Michael Catanzaro]

Goodness gracious, it is terrifying that removing headers can cause runtime failures, because we all expect that if it builds it must be good. Did any tests catch this?

[Carlos Garcia Campos]

"and it's causing a lot of unit tests to fail"