GNOME Bugzilla – Bug 784170
(WebKitWebProcess:19121): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed
Last modified: 2021-07-05 10:48:42 UTC
Lots of (WebKitWebProcess:19121): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed seen (but on a private site, so cannot post here for you to reproduce.) Debian Sid.
This is of absolutely no use without a backtrace. Run with G_DEBUG=fatal_warnings, and get a few backtraces, then post the representative one(s).
Yup that's the right answer, thanks Daniel. Well almost. Please use G_DEBUG=fatal-criticals instead. (Or fatal-warnings, with a hyphen, but that's not going to work if it hits some other warning first.) Please see https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for more information on how to get a stack trace (using G_DEBUG=fatal-criticals) if you're not familiar with how to do so. This will help us diagnose the issue. Thanks!
(In reply to Michael Catanzaro from comment #2) > Yup that's the right answer, thanks Daniel. Well almost. Please use > G_DEBUG=fatal-criticals instead. (Or fatal-warnings, with a hyphen, but > that's not going to work if it hits some other warning first.) Oops, thanks for correcting to the hyphen. Also, TIL that fatal-criticals exists! I've just been using fatal-warnings and doing "cont" until I get to the right one. :P
I'm used to it with other browsers. Probably something wrong with Debian, or me. Anyway at worst it just makes the calling shell window unreadable. Anyway, it will take me a long time to read how to make the traces. In the meantime. 1. apt-get install epiphany-browser 2.: $ epiphany fb.com ** (epiphany:20913): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files ** (WebKitWebProcess:20933): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files ** (WebKitWebProcess:20933): WARNING **: Error retrieving adblock filter: Operation not supported (WebKitWebProcess:20933): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (WebKitWebProcess:20933): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (WebKitWebProcess:20933): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (WebKitWebProcess:20933): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed
For what it's worth: the accessibility warning means your system does not have accessibility services installed, which is going to cause warnings in lots of apps. The failure to download adblock filters means your system does not have gvfs, which is probably going to cause serious breakage in lots of apps, so you'll definitely want to install that too. If you expected Debian to provide those for you (as it really ought to), then you might want to report these issues to Debian. The criticals after that are probably Epiphany bugs. I can't reproduce the issue with fb.com, unfortunately.
OK now I installed gvfs, and gnome-accessibility-themes, which is what I guess you mean, and... all seven warnings still occur.
(In reply to Dan Jacobson from comment #4) > Anyway, it will take me a long time to read how to make the traces. apt-get install gdb G_DEBUG=fatal-criticals gdb ./hx1ed > [gdb opens and gives you its own prompt, so you type:] run > [wait for the mentioned critical warning] > [gdb halts at a breakpoint caused by the G_DEBUG] > [you type:] bt > [gdb will print the backtrace leading up to the critical] You can then paste everything after the "bt" and before the next empty prompt here, and Bugzilla will automatically format/fold it as a backtrace.
(In reply to Daniel Boles from comment #7) > G_DEBUG=fatal-criticals gdb ./hx1ed lol, "gdb epiphany" even.
(In reply to Dan Jacobson from comment #6) > OK now I installed gvfs, There are a bunch of subpackages too, which I can't keep track of; one of them handles HTTP. It's something your distro should have handled for you. > and gnome-accessibility-themes, which is what I > guess you mean, and... all seven warnings still occur. Nope... gnome-accessibility-themes sounds like something from GNOME 2 maybe, or maybe creative packaging. There are a bunch of packages that handle accessibility, and I'm not sure how to install and enable all the right ones. It's again something your distro should have handled for you.
$ epiphany gives me the seven warnings. $ G_DEBUG=fatal-criticals gdb epiphany GNU gdb (Debian 8.0-1) 8.0... Reading symbols from epiphany...(no debugging symbols found)...done. (gdb) run gives me many more warnings that just keep coming. No gdb prompt to type at. $ gdb epiphany gives me the seven warnings, then comes to a rest. If I type ^Z I can get back to the gdb prompt. $ G_DEBUG=fatal-warnings gdb epiphany gives me one warning, and the gdb prompt! (gdb) r Starting program: /usr/bin/epiphany [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [New Thread 0xafc65b40 (LWP 8854)] ** (epiphany:8850): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files Thread 1 "epiphany" received signal SIGTRAP, Trace/breakpoint trap. 0xb303abc0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 (gdb) bt
+ Trace 237596
then just the constant rain of errors.. I'll ask the Debian maintainer to add the missing package dependencies alluded to in this bug, and/or add a epiphany-browser-dbg package with the symbols still in.
OK I filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865875 .
I mean http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866063 .
Hm, I'm surprised to see the criticals are related to the missing accessibility service. I guess this is a bug in atspi. It's bad for the accessibility service to be missing, but atspi should handle that case gracefully without emitting a bunch of criticals. Aside: If you're wondering what "atspi" stands for, it's probably "accessibility something (technology?) service provider interface".
(In reply to Michael Catanzaro from comment #13) > Hm, I'm surprised to see the criticals are related to the missing > accessibility service. But that's a warning. The critical for which this bug was really opened was not repro'd in the quoted gdb session. So we probably need 2 tickets.
Please, provide a backtrace of the original problem, not some other one.
OK I'm making progress. The adblocker warning must be http://lists.gnu.org/archive/html/bug-guix/2017-02/msg00007.html which I hope gets addressed. The accessibility warnings are due to missing at-spi2-core dependencies http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866063 and via that bug I now have the debugging symbols I need to try again on the affected machine tomorrow with the Criticals and report back here...
(In reply to Daniel Boles from comment #14) > (In reply to Michael Catanzaro from comment #13) > > Hm, I'm surprised to see the criticals are related to the missing > > accessibility service. > > But that's a warning. The critical for which this bug was really opened was > not repro'd in the quoted gdb session. So we probably need 2 tickets. My guess is that you did reproduce it. The critical is not actually going to print because of the use of G_DEBUG=fatal-criticals causing it to crash instead. At any rate, here we definitely have a critical from libatspi. To confirm for sure that it's the same one, you could install debugging symbols for glib and then take the backtrace again. Then, if you take the backtrace with 'bt full' instead of just 'bt', the stack would show the error message that would have been printed if not for the use of G_DEBUG=fatal-criticals. But I really strongly suspect that it's going to be "g_variant_new_string: assertion 'string != NULL' failed" (In reply to Dan Jacobson from comment #16) > OK I'm making progress. > The adblocker warning must be > http://lists.gnu.org/archive/html/bug-guix/2017-02/msg00007.html > which I hope gets addressed. That's caused by missing some expected gvfs backend causing GFile to not work. gvfs is a dependency of GNOME, so it's not really an Epiphany bug, but Epiphany could certainly do better here because it really shouldn't need gvfs to download a file when it's a web browser and could just use WebKit for the download, like it does for all other downloads. That's bug #776682.
(In reply to Michael Catanzaro from comment #17) > (In reply to Daniel Boles from comment #14) > > (In reply to Michael Catanzaro from comment #13) > > > Hm, I'm surprised to see the criticals are related to the missing > > > accessibility service. > > > > But that's a warning. The critical for which this bug was really opened was > > not repro'd in the quoted gdb session. So we probably need 2 tickets. > > My guess is that you did reproduce it. The critical is not actually going to > print because of the use of G_DEBUG=fatal-criticals causing it to crash instead. > At any rate, here we definitely have a critical from libatspi. I'm not the Dan you're looking for. :P And what he quoted above was not a critical, just a warning, and not the same message as in the title: (In reply to Dan Jacobson from comment #10) > $ G_DEBUG=fatal-warnings gdb epiphany > gives me one warning, and the gdb prompt! > (gdb) r > Starting program: /usr/bin/epiphany > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". > [New Thread 0xafc65b40 (LWP 8854)] > > ** (epiphany:8850): WARNING **: Error retrieving accessibility bus address: > org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not > provided by any .service files > > Thread 1 "epiphany" received signal SIGTRAP, Trace/breakpoint trap. > 0xb303abc0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 I can't see any reproduction of the title issue here: > GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed But I guess this is now about something else, or both, or who knows what.
(In reply to Daniel Boles from comment #18) > I'm not the Dan you're looking for. :P And what he quoted above was not a > critical, just a warning, and not the same message as in the title: I'm pretty sure the backtrace he posted really is for the critical we are investigating. With more debug symbols, we could know for sure.
# aptitude install gnome 0 packages upgraded, 456 newly installed, 0 to remove Need to get 340 MB/348 MB of archives. After unpacking 1,083 MB will be used. Do you want to continue? [Y/n/?] Nooooooooooooo # aptitude install gvfs-backends And indeed that makes the adblock message go away, at the price of 0 packages upgraded, 23 newly installed, 0 to remove Need to get 1,901 kB/4,364 kB of archives. After unpacking 22.7 MB will be used. Should I file a bug against Debian to require gvfs-backends or will this be fixed in epiphany bug #776682? The other problems I will attack tomorrow.
(In reply to Dan Jacobson from comment #20) > Should I file a bug against Debian to require gvfs-backends I don't know how Debian intends for this to work, but I would guess that it should be Recommended by GLib. And the at-spi stuff should probably be Recommended by GTK+. > or will this be > fixed in epiphany bug #776682? It should be, but that's low-priority and you're undoubtedly going to have problems with other applications without gvfs-backends installed.
OK added http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866121 (add Depends gvfs-backends) (Hope gvfs-backends is the right one missing, out of the 22 others that came along when I installed it.)
OK today I'm back on the 32 bit machine with the more problems. 1. installing at-spi2-core cleans up the accessibility messages. Good! 2. installing gvfs-backend does NOT fix the adblock message on this machine. BAD. 3. OK now with epiphany-browser-dbgsym installed, here is a summary of what happened, $ G_DEBUG=fatal-criticals gdb epiphany Reading symbols from epiphany...Reading symbols from /usr/lib/debug/.build-id/27/d78b2d1fe0e9ca84414d56fe29b3234adefb2d.debug...done. done. (gdb) r Starting program: /usr/bin/epiphany [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [New Thread 0xa4536b40 (LWP 9662)]... ** (WebKitWebProcess:9648): WARNING **: Error retrieving adblock filter: The specified location is not supported [New Thread 0xa3d35b40 (LWP 9669)] (WebKitWebProcess:9648): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed [Thread 0xa4d37b40 (LWP 9656) exited] [New Thread 0xa4d37b40 (LWP 9672)] [Thread 0xa3d35b40 (LWP 9669) exited] ** (WebKitWebProcess:9671): WARNING **: Error retrieving adblock filter: The specified location is not supported (WebKitWebProcess:9671): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed [Thread 0xa4d37b40 (LWP 9672) exited] [New Thread 0xa4d37b40 (LWP 9687)] C-c C-c Thread 1 "epiphany" received signal SIGINT, Interrupt. 0xb7fd9cf9 in __kernel_vsyscall () (gdb) q A debugging session is active. Inferior 1 [process 9626] will be killed. Quit anyway? (y or n) y So sorry, it never stops at a breakpoint. It just loops. Now trying with $ G_DEBUG=fatal-warnings gdb epiphany ** (WebKitWebProcess:9976): WARNING **: Error retrieving adblock filter: The specified location is not supported [Thread 0xa41ffb40 (LWP 9978) exited] [New Thread 0xa41ffb40 (LWP 9988)] ** (WebKitWebProcess:9987): WARNING **: Error retrieving adblock filter: The specified location is not supported [Thread 0xa41ffb40 (LWP 9988) exited] [New Thread 0xa41ffb40 (LWP 9999)] same looping. No breakpoint. So I need new debugging instructions. And just now when starting epiphany I saw "Oops! There may be a problem The site at about:blank may have caused Web to close unexpectedly. If this happens again, please report the problem to the Debian developers." But I'll pretend it didn't happen unless it happens more often.
Oh whoops, what I forgot to mention is that this time the critical is coming from the web process, not the UI process. So the backtrace has to come from the web process. Easiest way on Debian is to ensure you have only one Epiphany window with one tab open (running under G_DEBUG=fatal-criticals as before), then attach to it using 'gdb -p `pidof WebKitWebProcess`'. Then type 'c' to continue the web process, reproduce the bug, and take the backtrace as before. (In reply to Dan Jacobson from comment #23) > And just now when starting epiphany I saw > > "Oops! There may be a problem > The site at about:blank may have caused Web to close unexpectedly. > > If this happens again, please report the problem to the Debian > developers." Again, this is always a web process crash worth reporting separately with a backtrace. Especially interesting if you've got it into a bad state. Ignore the suggestion to report it to Debian, it's much better to report here.
(In reply to Michael Catanzaro from comment #24) > then attach to it using 'gdb -p `pidof WebKitWebProcess`' And I'm not sure about Debian, but on most distros now you'd need to run that as root or under sudo.
Created attachment 354633 [details] Bad debugginf instructions results I'm saying what you are telling me to do is wrong. When I do it the process just keeps on dying and spawning other processes, about once every five seconds. It never stops, so there is no chance to get back to the gdb prompt to do anything or continue a connected process because there is no process stopped at a breakpoint because all processes are either running or died, none stopped.
I'm sorry. I think this is what you want: $ G_DEBUG=fatal-criticals epiphany& [1] 2873 $ (WebKitWebProcess:2892): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (WebKitWebProcess:2914): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (WebKitWebProcess:2929): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (WebKitWebProcess:2944): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (WebKitWebProcess:2959): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (WebKitWebProcess:2974): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (WebKitWebProcess:2989): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed $ gdb -p `pidof WebKitWebProcess` GNU gdb (Debian 8.0-1) 8.0... Attaching to process 3004 [New LWP 3006] [New LWP 3007] [New LWP 3008] [New LWP 3009] [New LWP 3010] [New LWP 3011] [New LWP 3012] [New LWP 3013] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". 0xb1962198 in ?? () from /lib/i386-linux-gnu/libc.so.6 (gdb) c Continuing. [New Thread 0xa58b0b40 (LWP 3024)] [New Thread 0xa50afb40 (LWP 3025)] [New Thread 0xa48aeb40 (LWP 3028)] (WebKitWebProcess:3004): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed Thread 1 "WebKitWebProces" received signal SIGTRAP, Trace/breakpoint trap. 0xb2701bc0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 (gdb) bt
+ Trace 237599
(bt full just has lots of "No symbol table info available.")
Yeah, that's almost what we want. Now you just need to install debuginfo for glib and WebKit for it to be useful.
Maybe debuginfo is not a Debian thing, https://www.google.com.tw/search?q=debuginfo+debian
via Google for "debian debug info": https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Oh I see, I should # apt-get install libwebkit2gtk-4.0-37-dbgsym libglib2.0-0-dbgsym OK I'll try that.
Note this bug only occurs on 32 bit machines... (gdb) c Continuing. (WebKitWebProcess:1801): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed [Thread 0xa50afb40 (LWP 1823) exited] Thread 1 "WebKitWebProces" received signal SIGTRAP, Trace/breakpoint trap. _g_log_abort (breakpoint=1) at ../../../../glib/gmessages.c:549 549 in ../../../../glib/gmessages.c (gdb) bt full
+ Trace 237607
(gdb)
This backtrace is clearly not for the same critical you reported earlier. The critical in comment #10 is a bug in at-spi. This new one is obviously a WebKit bug that needs to be reported elsewhere. (You have already done so, in bug #784234.)
(In reply to Michael Catanzaro from comment #33) > This backtrace is clearly not for the same critical you reported earlier. > The critical in comment #10 is a bug in at-spi. This new one is obviously a > WebKit bug that needs to be reported elsewhere. (You have already done so, > in bug #784234.) This thread is a mess. It was opened at ephy for a critical, which apparently is already reported elsewhere, but then halfway through it suddenly turned into a bug for at-spi about a warning. Is there a reset button somewhere?
(In reply to Daniel Boles from comment #34) > This thread is a mess. Yup. > It was opened at ephy for a critical, which > apparently is already reported elsewhere, but then halfway through it > suddenly turned into a bug for at-spi about a warning. Is there a reset > button somewhere? The critical that was originally reported in the first comment is coming from at-spi. Other issues should be reported elsewhere.
All I know is I am giving you the trace for the item mentioned in the title of this bug report, which has never changed.
The problem is, you've so far found two or maybe three completely different bugs that incredibly all result in this "g_variant_new_string: assertion 'string != NULL' failed" critical. They all need to be tracked separately. The first one you found was an at-spi issue. We can't fix that in Epiphany. So I reassigned this bug to at-spi. All the others need to be reported separately. You've filed so many bug reports recently, I can't keep track and have no clue if that's happened or not We can't track multiple issues in the same bug report: that's too confusing and never works well. You can look at the backtraces to see if the issues are related. The first trace in comment #10 is clearly coming from at-spi, while this latest trace looks completely different and is clearly coming from WebKit. Not surprising, because you installed some accessibility package and the original critical is probably gone now.
OK I retitled http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866063 to 'Add Depends: at-spi2-core' and the other problems are NOTGNOME.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/at-spi2-atk/-/issues/ Thank you for your understanding and your help.