v40 not working at all #21
Comments
|
Please post a backtrace for the web process crash ( Since elementary does not have coredumpctl working by default, you'll have to research how to get that working. |
|
Isn't this a problem for you right now? Then it must be something with the elementary devs should solve. This makes this issue unfunctional. Closing it then. BTW I couldn't get to have an output, i've installed debug package for org.gnome.Epiphany too but it gives this: |
|
Looks like I am getting the same crash on Fedora 34 (beta). |
|
$ flatpak-coredumpctl org.gnome.Epiphany For help, type "help". |
|
Well you're missing debuginfo. Can you please run |
|
I think what's happening is the web process crashes immediately after it is launched. GSubprocess notices, g_subprocess_get_identifier() returns nullptr, and then the UI process crashes when passing that to g_ascii_strtoll(). The UI process should crash if the web process crashes on startup, but it should crash better, with an assert rather than a null pointer dereference. To get a backtrace for the web process crash, look up the pid of the crashing web process using |
|
Well, I installed all the packages now and now get this: flatpak-coredumpctl org.gnome.Epiphany For help, type "help". There's a gdb process causing 100% cpu load on one core but there doesn't seem to be a crash now. coredumpctl does not show any dumps after 10:29:07 CEST this morning when I posted the above output. Also, there is no window popping up when run in flatpak-coredumpctl. I window is drawn however when run normally. No web rendering but menus etc seem to be working fine. |
Patience! :) Either it will print a backtrace, or you can report a bug against gdb if not. But it will probably print a backtrace. It just takes a while because the debuginfo is huge.
Perhaps you mistyped here? You cannot use flatpak-coredumpctl to do anything other than open a core dump in gdb. |
|
After letting it run for about 10 minutes I got another entry in coredumpctl: ... How would I tell if this is a web or UI process? |
|
No idea if this is helpful: flatpak-coredumpctl org.gnome.Epiphany -m 16784 For help, type "help". warning: the debug information found in "/usr/lib/debug//usr/lib/x86_64-linux-gnu/libicudata.so.67.1.debug" does not match "/usr/lib/x86_64-linux-gnu/libicudata.so.67" (CRC mismatch). warning: the debug information found in "/usr/lib/debug//usr/lib/x86_64-linux-gnu/libicudata.so.67.1.debug" does not match "/usr/lib/x86_64-linux-gnu/libicudata.so.67" (CRC mismatch). warning: the debug information found in "/usr/lib/debug//usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0.debug" does not match "/usr/lib/x86_64-linux-gnu/libX11-xcb.so.1" (CRC mismatch). warning: the debug information found in "/usr/lib/debug//usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0.debug" does not match "/usr/lib/x86_64-linux-gnu/libX11-xcb.so.1" (CRC mismatch). Core was generated by `epiphany'. |
epiphany is the UI process. The web process is WebKitWebProcess.
That's a great backtrace for the UI process crash, which confirms my previous theory and is enough to fix the UI process crash. I will fix that now. As for the web process side of this... if you really don't see WebKitWebProcess crashing in coredumpctl, then that's real bad luck. Check your journal and look for anything at all suspicious. Maybe it's being killed by systemd-oomd or something weird like that? |
|
Just tried again, this is the full journal output: Apr 05 17:16:29 flippy systemd[1153]: Started app-flatpak-org.gnome.Epiphany-38448.scope. Apr 05 17:17:28 flippy systemd[1]: systemd-coredump@0-48094-0.service: Deactivated successfully. |
|
Well it looks like nothing is happening to the web process at all, but that seems unlikely. Let me install this and see if I can reproduce.... |
|
I've determined this requires both (a) flatpak, and (b) a non-English locale to reproduce. With Tech Preview: However @alatiera reports that's not enough to make it crash for him. He doesn't see the crash unless he sets some random environment variable to include a UTF-8 character, e.g. There are no web process crashes in coredumpctl because the web process is not actually being launched. I missed this very important information from the first comment: "Web process crashed" is a lie, WebKit reports a web process crash whenever the connection to the web process closes unexpectedly, but a crash is not the only reason that could happen. In this case, it happens because flatpak-spawn quits. |
|
Oh and this very important tidbit at the top of the log: That's not good. |
|
So here's what I have, I get a "Locale not supported" warning first and then the process crashes. With If I override If I add a random env var with an emoji afterwards it crashes again SIdenote, |
|
These are from my system with UK locales: First noticed this issue on a machine with UK lang but Greek format locales |
|
Region & Language > Language is set to "English United States)" and Region & Language > Formats to "Deutschland (Deutsch)" which results in this output:
Setting all LC_* to en_US.UTF-8 fixes the problem... |
|
Hmm: The Spanish locale is broken in the sandbox for unknown reasons. But not when using flatpak-spawn: because flatpak-spawn runs the process with the host environment. But after https://trac.webkit.org/changeset/272179/webkit, we now manually forward the entire environment to flatpak-spawn. So WebKit will now do something like this: When the locale is broken, we fall back to C locale, and then UTF-8 characters like 📦 are no longer allowed, so that's why the 📦 in PS1 is causing everything to blow up. For example: OK, so now we have a minimal reproducer that doesn't involve WebKit or Epiphany at all. I'm guessing that locales are somehow generally broken in the runtime? @alatiera is it time to move this issue to gnome-build-meta? |
|
Checking Epiphany's Add Language dialog, I see only three locales exist within the runtime: English (Canada), English (United Kingdom), and "System languages (en-US, en)" which is English (US). In contrast, Fedora's Epiphany presents me with several dozens of choices for locale. Selecting one of these locales using the LANG environment variable is not actually going to work, because translations are not going to be installed unless I install the relevant Fedora language pack, but at least it doesn't break and fall back to the C locale. I don't know how runtime locale extensions work, but it sure seems like the selected locale likely does not exist at all within the runtime. |
|
|
|
In my case I have: After changing my formats to German using the Region & Language panel, Epiphany starts crashing. flatpak config seems to notice immediately: I guess the problem is use of German formats with English locale. But again, this is not an Epiphany or WebKit bug because flatpak-spawn itself is broken. IMO it is reasonable for WebKit to crash if flatpak-spawn is not working. @veyselerden please run |
|
P.S. Workaround is to run with WEBKIT_FORCE_SANDBOX=0 to disable the flatpak-spawn subsandboxes. (You're still protected by flatpak's primary sandbox, but browser tabs will no longer be subsandboxed separately from each other.) |
|
BTW I will fix the UI process crash in https://bugs.webkit.org/show_bug.cgi?id=224209, but that is not the main problem here. |
|
So this is a case of flatpak not working correctly by default with mixed locales. For some reason, flatpak doesn't seem to download all the locales by default (See flatpak/flatpak#3514 flatpak/flatpak#3563 flatpak/flatpak#3712). What you can do is to set the correct languages in Of course, what I'm describing above is a workaround, and flatpak should do the right thing by default. |
|
Thanks Abderrahim. Since there are no changes to make in Epiphany, I'm going to close this in favor of any of flatpak/flatpak#3514 flatpak/flatpak#3563 flatpak/flatpak#3712, which are all duplicates of each other. Once those are fixed, Epiphany will stop crashing. In the meantime, workaround is to manually disable the sandbox or not use mixed locales. |
|
Let's continue in flatpak/flatpak#3712. |
|
FYI: I downgraded Ephy to previous version (3.38) with: ... and the issue doesn't go away. This is probably because |
|
It's a webkit issue, you want to downgrade the runtime as well. Try |
|
Downgrading the runtime won't work, we update webkit in older ones too, cause security and all. |
|
It will, that's the last commit before webkit 2.32.0. |
|
You'll have to pin to that runtime version forever until someone has time to fix the flatpak bug. Sorry. :/ |
I figured, I will wait for the fix. Just wanted to log the info that this is really unrelated to Ephy v40 and can be reproduced even in previous versions, if the runtime (and its webkit) has been already updated.. |
|
i have this issue only after updating Platform while Web is running. restarting Web fixes it |
|
@2-www Sorry, but any good reason why are you using a 2-years old version of a browser? This has been fixed, if you have similar problem, it's probably better to open a new issue (and mention this one if you think it's helpful). PS: also, updating components or runtimes while apps are running on them is bound to cause some trouble, I don't consider it an issue. Even my phone works the same way. |
sorry, i didn't notice it's 2021 :( i opened flatpak/flatpak#5398
but gnome-software can do this in background without asking the user |
This is, by design, always safe. Any exception to that is a flatpak bug. In this case related to sub-sandboxes. |
|
Is it still safe even if you're using flatpak-spawn to launch subprocesses? Need to be sure that flatpak-spawn launches the same version of the application and runtime that was launched originally, not the currently-installed version. Otherwise, WebKit will crash on IPC format assertions. That will not look similar to this issue to an experienced user who looks at the backtrace, but I see how it could be confused with an extremely generic "not working at all" bug report. |
|
@mcatanzaro EDIT: Their issue may be unrelated but at the very least subsandboxes are meant to be reliable through updates. |
On both elementary OS 5.1 and 6 it stays like this but idk if it's anything with the elementary OS or the flatpak version itself.
Terminal output:
`(epiphany:2): epiphany-WARNING **: 20:20:43.138: Web process crashed
flatpak-spawn: Invalid byte sequence in conversion input
Try "flatpak-spawn --help" for more information.
Note that the directories
'/var/lib/flatpak/exports/share'
'/home/veysel/.var/app/org.gnome.Epiphany/data/flatpak/exports/share'
are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.
error: app/org.gnome.Epiphany/x86_64/stable (commit 32b86d07919232c5c0fd18449eaa8dd6a33a97c3e6a050703bf097228dde9a33) not installed`
The text was updated successfully, but these errors were encountered: