GNOME Bugzilla – Bug 719399
[extensions] AddBlock shows CRITICAL when the regex compilation fails
Last modified: 2014-01-02 20:35:29 UTC
Debian Testing $ dpkg -l| grep epi ii epiphany-browser 3.8.2-4 amd64 Intuitive GNOME web browser ii epiphany-browser-data 3.8.2-4 all Data files for the GNOME web browser ii epiphany-browser-dbg 3.8.2-4 amd64 Debugging symbols for the GNOME web browser Everytime we launch ephy we get: ** (WebKitWebProcess:6193): WARNING **: uri_tester_compile_regexp: Error while compiling regular expression /cdn-cgi/pe/bag\?r[]=.*cpalead.com at char 34: missing terminating ] for character class (WebKitWebProcess:6193): GLib-CRITICAL **: g_regex_unref: assertion `regex != NULL' failed
The failing uri comes from: https://easylist-downloads.adblockplus.org/easylist.txt Although the compilation shouldn't fail, I suppose this is a bug in the addblock list itself or, maybe, lack of using the G_REGEX_JAVASCRIPT_COMPAT GRegexCompileFlags[1] In any case, the GLib-CRITICAL should be avoided. [1] https://developer.gnome.org/glib/2.38/glib-Perl-compatible-regular-expressions.html#G-REGEX-JAVASCRIPT-COMPAT:CAPS
It fixed in 79db933d667fe0208aaf1fc58f8bd84d6a0dc162 commit. I not get more this error with epiphany from master.
Created attachment 262918 [details] [review] uri-tester: Compile regex in JavaScript compatibility mode AddBlock regex now are compiled in JavaScript compatibility mode and the resulting pointer is not tried to be cleared if there is also a returning error as it will always be NULL in that case.
You attached a patch, so reopened.
(In reply to comment #2) > It fixed in 79db933d667fe0208aaf1fc58f8bd84d6a0dc162 commit. > I not get more this error with epiphany from master. Is this even related?
(In reply to comment #5) > (In reply to comment #2) > > It fixed in 79db933d667fe0208aaf1fc58f8bd84d6a0dc162 commit. > > I not get more this error with epiphany from master. > > Is this even related? I think it relate to this: ** (WebKitWebProcess:6193): WARNING **: uri_tester_compile_regexp: Error while compiling regular expression /cdn-cgi/pe/bag\?r[]=.*cpalead.com at char 34: missing terminating ] for character class bot not to this: (WebKitWebProcess:6193): GLib-CRITICAL **: g_regex_unref: assertion `regex != NULL' failed
Created attachment 262919 [details] Simple test case showing the WARNING
(In reply to comment #2) > It fixed in 79db933d667fe0208aaf1fc58f8bd84d6a0dc162 commit. > I not get more this error with epiphany from master. That's a different critical warning I fixed. If you don't see the warning it is for a different reason.
Review of attachment 262918 [details] [review]: ::: embed/uri-tester.c @@ +478,2 @@ /* TODO: Play with optimization flags */ + regex = g_regex_new (patt, G_REGEX_OPTIMIZE | G_REGEX_JAVASCRIPT_COMPAT, Why is this necessary? @@ -483,3 @@ g_warning ("%s: %s", G_STRFUNC, error->message); g_error_free (error); - g_clear_pointer (®ex, g_regex_unref); If this was already the case, then this cleanup is not related to the bug.
Basically it's two different warnings, so please two patches.
(In reply to comment #9) > Review of attachment 262918 [details] [review]: > > ::: embed/uri-tester.c > @@ +478,2 @@ > /* TODO: Play with optimization flags */ > + regex = g_regex_new (patt, G_REGEX_OPTIMIZE | G_REGEX_JAVASCRIPT_COMPAT, > > Why is this necessary? ... Because without it the compilation fails, as it is shown in the description of the bug: (In reply to comment #0) > ** (WebKitWebProcess:6193): WARNING **: uri_tester_compile_regexp: Error while > compiling regular expression /cdn-cgi/pe/bag\?r[]=.*cpalead.com at char 34: > missing terminating ] for character class With it, all the compilations coming from https://easylist-downloads.adblockplus.org/easylist.txt succeed. (In reply to comment #9) > @@ -483,3 @@ > g_warning ("%s: %s", G_STRFUNC, error->message); > g_error_free (error); > - g_clear_pointer (®ex, g_regex_unref); > > If this was already the case, then this cleanup is not related to the bug. That cleanup spits the CRITICAL shown in the description of the bug: (In reply to comment #0) > (WebKitWebProcess:6193): GLib-CRITICAL **: g_regex_unref: assertion `regex != > NULL' failed Since it tries to do a "g_regex_unref" on a NULL pointer, happening because the compilation fails with the WARNING.
> ... > > Because without it the compilation fails, as it is shown in the description of > the bug: > Why does it fail without it? > > Since it tries to do a "g_regex_unref" on a NULL pointer, happening because the > compilation fails with the WARNING. Yes, but the compilation could fail for many other reasons, and in any such cases the g_regex_unref() call is unnecessary.
Created attachment 262929 [details] [review] uri-tester: Compile regex in JavaScript compatibility mode AddBlock regexes now are compiled in JavaScript compatibility mode to avoid the errors happening from using the patterns from https://easylist-downloads.adblockplus.org/easylist.txt .
Moved the second part of the previous patch to bug 719405.
Review of attachment 262929 [details] [review]: Okay, I suppose, from reading in adblockplus.org, that the lists compiled are meant to be used from JS, so in that case it makes sense to use a JS-compatibility mode. Please commit to gnome-3-10 too.
Pushed.
*** Bug 706481 has been marked as a duplicate of this bug. ***