Bug 233580 – specific urls refuse to load and cause the browser to crash

• Component: WebKitGTK
• Status: RESOLVED DUPLICATE

[LJoris]

Created attachment 445307 [details]
coredump of a crash instance

This issue is also being tracked as https://gitlab.gnome.org/GNOME/epiphany/-/issues/1642

For a seemingly random yet reproducible number of URL the browser tab refused to fully load, there is a short display of the website rendering to then fail with a message the page is unable to load.

The URLs for which this could be reproduced.

when loading https://www.nu.nl/ 3x (tab crash)
[di nov 23 20:19:31 2021] traps: eadedCompositor[27721] trap int3 ip:7febcb7e1647 sp:7feb4cbfde30 error:0 in libglib-2.0.so.0.6800.1[7febcb79e000+8d000]
[di nov 23 20:19:48 2021] traps: eadedCompositor[28001] trap int3 ip:7fe906bc2647 sp:7fe887efde30 error:0 in libglib-2.0.so.0.6800.1[7fe906b7f000+8d000]
[di nov 23 20:21:23 2021] traps: eadedCompositor[28919] trap int3 ip:7fb0f77a8647 sp:7fb078bfde30 error:0 in libglib-2.0.so.0.6800.1[7fb0f7765000+8d000]
another url causing crashes is https://www.trustedsec.com/blog/ 1x (tab crash)
[di nov 23 20:22:27 2021] traps: eadedCompositor[29306] trap int3 ip:7f08b0578647 sp:7f0842ffbe30 error:0 in libglib-2.0.so.0.6800.1[7f08b0535000+8d000]
another url causing a tab crash is https://cybersecurity.att.com/blogs/labs-research/hunting-for-linux-library-injection-with-osquery

all these cause coredump to be generated and can these can be reproduced reliably

There seems to be an underlying issue with AMD GPU drivers which aggrevates the problem.
Ironically, when running with open source AMD gpu drivers the tab crash did not happen but the browser froze the then have the system lock up.

Ubunt 21.04
AMD Ryzen 3700U

[Michael Catanzaro]

This looks to be identical to bug #233578? You posted the same backtrace in both issues?

[Michael Catanzaro]

I'm going to mark this as a duplicate of bug #233578, since the backtrace you posted is identical and having too many bugs open isn't helpful. If you have some reason to believe it's a different underlying issue from bug #233578, we could reconsider that, of course.

[Michael Catanzaro]

*** This bug has been marked as a duplicate of bug 233578 ***

[LJoris]

These are unique backtraces created on your request to create this separate issue.

For the past few days now i've been creating backtraces.

Here i created traces for eolie and epiphany separately.

this specific issue contains only backtraces for eolie

These all show /usr/bin/python3.9 as EXE which is entirely distinct from epiphany specific crashes.

What they do appear to have in common is they appear to be triggered by javascript and/or animated gif playback.

[Michael Catanzaro]

(In reply to LJoris from comment #4)
> These are unique backtraces created on your request to create this separate
> issue.

But it's obviously the same crash as bug #233578, so we only need one bug report open for it.

> For the past few days now i've been creating backtraces.
> 
> Here i created traces for eolie and epiphany separately.
> 
> this specific issue contains only backtraces for eolie
> 
> These all show /usr/bin/python3.9 as EXE which is entirely distinct from
> epiphany specific crashes.

No they don't. There's no eolie anywhere in the first backtrace here, nor in the first backtrace in bug #233578, because it's a web process crash, not a UI process crash. They both crash in Nicosia::GCGLLayer::makeContextCurrent. It's the same issue.

You do see eolie in the unrelated UI process crashes that you posted in bug #233578, but those are different issues.

> What they do appear to have in common is they appear to be triggered by
> javascript and/or animated gif playback.

In this case, the cause is actually WebGL triggering switch to accelerated compositing mode.