g_object_ref: assertion 'G_IS_OBJECT(object)' failed when opening non-HTML documents (e.g. RSS/Atom feeds)

[iamleot]

When opening non-HTML documents (e.g. RSS and Atom feeds) there are:

(<unknown>:21179): GLib-GObject-CRITICAL **: 02:22:30.288: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

(<unknown>:21179): GLib-GObject-CRITICAL **: 02:22:31.328: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

(<unknown>:21179): GLib-GObject-CRITICAL **: 02:22:31.329: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

(<unknown>:21179): GLib-GObject-CRITICAL **: 02:22:36.579: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

(<unknown>:21179): GLib-GObject-CRITICAL **: 02:22:37.088: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

This is with current master:

% ./vimb --bug-info
Commit:          3.2.0-56-ga9ed81e
WebKit compile:  2.22.2
WebKit run:      2.22.2
GTK compile:     3.22.30
GTK run:         3.22.30
libsoup compile: 2.62.3
libsoup run:     2.62.3
Extension dir:   /tmp/vimb/sandbox/usr/lib/vimb

Steps to reproduce

Go to XKCD, then RSS Feed and/or Atom Feed. (But probably other similar scenarios are possible.)

Expected behaviour

No GLib-GObject-CRITICAL messages expected.

Actual behaviour

GLib-GObject-CRITICAL messages printed.

(Unfortunately I was not able to investigate it further, hopefully I'll add more details as soon as possible!)

[iamleot]

A simpler way to reproduce it is by just creating an XML file with just:

% cat x.xml
<?xml version="1.0" ?>

Then:

% vimb x.xml

...after x.xml is showed (it will print that the XML file contains errors), opening any website (e.g. http://www.example.org) and then going back in the history to redisplay x.xml should trigger:

(<unknown>:29444): GLib-GObject-CRITICAL **: 17:06:19.420: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

[fanglingsu]

@iamleot Thank you for the report. But I can't reproduce this on

Commit:          3.2.0-56-ga9ed81e8
WebKit compile:  2.22.2
WebKit run:      2.22.2
GTK compile:     3.24.1
GTK run:         3.24.1
libsoup compile: 2.64.1
libsoup run:     2.64.1

No message are printed to cli on my system. Have you some glib/gtk/webkit related environment variables set?

[iamleot]

Daniel Carl writes:

@iamleot Thank you for the report. But I can't reproduce this on

Commit:          3.2.0-56-ga9ed81e8
WebKit compile:  2.22.2
WebKit run:      2.22.2
GTK compile:     3.24.1
GTK run:         3.24.1
libsoup compile: 2.64.1
libsoup run:     2.64.1

No message are printed to cli on my system. Have you some glib/gtk/webkit related environment variables set?

Nope, no glib/gtk/webkit variable environment sets.

[iamleot]

After trying to further investigate it... Actually the PID that prints that is WebKitWebProcess, so I'm not sure if that's a Vimb issue or a WebKitGTK+ one. At the same time I have tried to do the same of opening https://xkcd.com and then its RSS and Atom feeds with MiniBrowser (part of WebKitGTK+) and in that case I do not have any assertion messages printed out.

I have also tried to put breakpoint in the WebKitWebProcess process via rbreak g_assert.* without luck (I think that if we can get the bt when the assertion happens probably this will shed some light). I should retry by rebuilding glib2 with debug symbols.

[fanglingsu]

@iamleot This might be rlated to some of the dom processing we do in the webextension (check for scroll position, ...).

[iamleot]

Hello Daniel,

Daniel Carl writes:

@iamleot This might be rlated to some of the dom processing we do in the webextension (check for scroll position, ...).

It seems so! And finally - after rebuilding glib2 with the debug symbols - I have found a way to properly debug that (this is when opening RSS xkcd feed):

(gdb) b g_object_ref if _object == NULL
Breakpoint 1 at 0x769c87a12bfa: file gobject.c, line 3202.
(gdb) c
Continuing.
[New LWP 16 of process 12530]
[New LWP 15 of process 12530]
[New LWP 14 of process 12530]
[Switching to LWP 1 of process 12530]

Thread 10 hit Breakpoint 1, g_object_ref (_object=0x0) at gobject.c:3202
3202    gobject.c: No such file or directory.
(gdb) bt
#0  g_object_ref (_object=0x0) at gobject.c:3202
#1  0x0000769c9318eb83 in WebKit::kit(WebCore::Node*) () from /usr/pkg/lib/libwebkit2gtk-4.0.so.37
#2  0x0000769c9318e529 in WebKit::kit(WebCore::Document*) () from /usr/pkg/lib/libwebkit2gtk-4.0.so.37
#3  0x0000769c931b6270 in webkit_dom_dom_window_get_document () from /usr/pkg/lib/libwebkit2gtk-4.0.so.37
#4  0x0000769c931b6df0 in webkit_dom_dom_window_get_property(_GObject*, unsigned int, _GValue*, _GParamSpec*) () from /usr/pkg/lib/libwebkit2gtk-4.0.so.37
#5  0x0000769c87a16165 in object_get_property (value=0x7f7fff4c4e20, pspec=0x769c8cdeb8b0, object=0x769c8c902b00) at gobject.c:1396
#6  g_object_get_valist (object=0x769c8c902b00, first_property_name=<optimized out>, var_args=<optimized out>) at gobject.c:2424
#7  0x0000769c87a165db in g_object_get (_object=0x769c8c902b00, first_property_name=0x769c35c056de "document") at gobject.c:2514
#8  0x0000769c35c042e0 in on_editable_change_focus (target=0x769c8c902b00, event=0x769c9211c530, page=0x769c8d1510a0) at ext-main.c:467
(gdb) f 8
#8  0x0000769c35c042e0 in on_editable_change_focus (target=0x769c8c902b00, event=0x769c9211c530, page=0x769c8d1510a0) at ext-main.c:467
467             g_object_get(target, "document", &doc, NULL);
(gdb) list
462         WebKitDOMElement *active;
463         GVariant *variant;
464         char *message;
465
466         if (WEBKIT_DOM_IS_DOM_WINDOW(target)) {
467             g_object_get(target, "document", &doc, NULL);
468         } else {
469             /* target is a doc document */
470             doc = WEBKIT_DOM_DOCUMENT(target);
471         }

I hope to investigate further this evening/night!

[fanglingsu]

@iamleot The DOM API seeps to be deprecated. So this issue might be a good reason to switch partially to the JavaScript Core API.

[iamleot]

Hello @fanglingsu! Yes, that's probably a better idea to investigate porting the code to the new API.

So, JFTR, this will be probably obsoleted/closed when #525 is addressed.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity within the last 60 days. It will be closed after 7 days if no further activity occurs. Thank you for your contributions.

[iamleot]

JFTR, this is still reproducible for me with current HEAD (using wip/vimb-git package in pkgsrc-wip):

% vimb --bug-info
Commit:          3.3.0-11-g020ae90
WebKit compile:  2.22.5
WebKit run:      2.22.5
GTK compile:     3.24.2
GTK run:         3.24.2
libsoup compile: 2.64.2
libsoup run:     2.64.2
Extension dir:   /usr/pkg/lib/vimb

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity within the last 60 days. It will be closed after 7 days if no further activity occurs. Thank you for your contributions.

[iamleot]

stale[bot] writes:

This issue has been automatically marked as stale because it has not had activity within the last 60 days. It will be closed after 7 days if no further activity occurs. Thank you for your contributions.

Activity! (despite being stale it's still relevant and reproducible with current Git HEAD)