Bug 233578 – [GTK] system freeze when playing an animated gif, crash in Nicosia::GCGLLayer::makeContextCurrent when creating WebGL context

• Status: NEW
• Component: WebKitGTK

[LJoris]

Created attachment 445302 [details]
backtrace of eolie 105511

This is also tracked as issue https://gitlab.gnome.org/World/eolie/-/issues/389 

The issue can be reproduced by starting a web application for twitter and playing an animated gif in this session. It was not tested if the system freeze also occurs when playing video.

os= Ubuntu 21.04
CPU/GPU = AMD Ryzen 3700U

[LJoris]

increased severity to blocker due to system freeze

[Michael Catanzaro]

The crash is bug #201507. We've struggled for years to find a reproducer for this. If you're able to trigger it reliably, then you're probably going to be a hero here.

The system freeze is obviously not our fault though. That said, check to make sure WebKit is not using an excessive amount of RAM. If RAM usage looks good, then I wonder if you have uncovered a bug in mesa. If not, who knows where....

[LJoris]

Sorry to say i've likely mixed up some things here swichting between too many topics too often.

The Twitter Web App is one run in epiphany but the backtrace here is for an Eolie crash.

I've just crashed eolie again and am attaching another backtrace.

[Michael Catanzaro]

*** Bug 233580 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

(In reply to LJoris from comment #3)
> Sorry to say i've likely mixed up some things here swichting between too
> many topics too often.
> 
> The Twitter Web App is one run in epiphany but the backtrace here is for an
> Eolie crash.

It's exactly the same crash, and I was going to say "the problem is your EGL is somehow broken," but... last I checked, you were using X11 and therefore getting GLX rather than EGL, right? Could you please open up webkit://gpu, copy/paste the output into a file, and attach it here?

[LJoris]

Created attachment 445313 [details]
eolie crash on tab loading 23839

crash was triggered by enabled use of media, images and loading both

the att.com and nu.nl URL
the nu.nl URL redirects to https://myprivacy.dpgmedia.be/ or https://myprivacy.dpgmedia.nl/ depending on what content loads after which the crash is produced, now trying to reproduce

[Michael Catanzaro]

Also, please confirm what WebKitGTK version you have (easiest way is to check the About dialog in Epiphany).

[Michael Catanzaro]

(In reply to LJoris from comment #6)
> Created attachment 445313 [details]
> eolie crash on tab loading
> 
> crash was triggered by enabled use of media, images and loading both

Nope, this one is an unrelated crash in WebKitWebsiteDataStore. Weird. That's definitely a WebKit bug, but it's not *this* bug. Could you report a separate bug for it please?

[LJoris]

Created attachment 445315 [details]
webkit-gpu output from epiphany

eolie does not permit webkit://gpu, showing output from epiphany

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #5)
> It's exactly the same crash, and I was going to say "the problem is your EGL
> is somehow broken," but... last I checked, you were using X11 and therefore
> getting GLX rather than EGL, right?

OK, I see you've indeed switched from X11 to Wayland. So this issue is different from https://gitlab.gnome.org/GNOME/epiphany/-/issues/1642#note_1317772.

[LJoris]

I've been using wayland for every session and every coredump after you mentioned it was considered obsolted in terms of development efforts.

[LJoris]

the syslog output from eolie, paired with a backtrace should this help

Nov 29 21:32:14 mymachine systemd-coredump[17556]: Process 17461 (python3) of user 1010 dumped core.#012#012Stack trace of thread 17461:#012#0  0x00007f8d3c22efbb __GI_raise (libc.so.6 + 0x40fbb)#012#1  0x00007f8d3c214864 __GI_abort (libc.so.6 + 0x26864)#012#2  0x00007f8d38058ed2 _dbus_abort (libdbus-1.so.3 + 0xbed2)#012#3  0x00007f8d3807c680 _dbus_warn_check_failed (libdbus-1.so.3 + 0x2f680)#012#4  0x00007f8d3806b922 dbus_message_new_method_call (libdbus-1.so.3 + 0x1e922)#012#5  0x00007f8d380b0261 socket_embed_hook (libatk-bridge-2.0.so.0 + 0x11261)#012#6  0x00007f8d213b6510 _ZN6WebKit12WebPageProxy21bindAccessibilityTreeERKN3WTF6StringE (libwebkit2gtk-4.0.so.37 + 0xb8a510)#012#7  0x00007f8d20f4b54f _ZN3IPC22callMemberFunctionImplIN6WebKit12WebPageProxyEMS2_FvRKN3WTF6StringEESt5tupleIJS4_EEJLm0EEEEvPT_T0_OT1_St16integer_sequenceImJXspT2_EEE (libwebkit2gtk-4.0.so.37 + 0x71f54f)#012#8  0x00007f8d20f40430 _ZN6WebKit12WebPageProxy17didReceiveMessageERN3IPC10ConnectionERNS1_7DecoderE (libwebkit2gtk-4.0.so.37 + 0x714430)#012#9  0x00007f8d2117281b _ZN3IPC18MessageReceiverMap15dispatchMessageERNS_10ConnectionERNS_7DecoderE (libwebkit2gtk-4.0.so.37 + 0x94681b)#012#10 0x00007f8d21271517 _ZN6WebKit15WebProcessProxy17didReceiveMessageERN3IPC10ConnectionERNS1_7DecoderE (libwebkit2gtk-4.0.so.37 + 0xa45517)#012#11 0x00007f8d2116baa5 _ZN3IPC10Connection15dispatchMessageESt10unique_ptrINS_7DecoderESt14default_deleteIS2_EE (libwebkit2gtk-4.0.so.37 + 0x93faa5)#012#12 0x00007f8d2116d9f2 _ZN3IPC10Connection24dispatchIncomingMessagesEv (libwebkit2gtk-4.0.so.37 + 0x9419f2)#012#13 0x00007f8d2ac7bdad _ZNK3WTF8FunctionIFvvEEclEv (libjavascriptcoregtk-4.0.so.18 + 0x14ecdad)#012#14 0x00007f8d2accb3cd operator() (libjavascriptcoregtk-4.0.so.18 + 0x153c3cd)#012#15 0x00007f8d2accbd03 operator() (libjavascriptcoregtk-4.0.so.18 + 0x153cd03)#012#16 0x00007f8d3b5017ef g_main_context_dispatch (libglib-2.0.so.0 + 0x557ef)#012#17 0x00007f8d3b554d28 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa8d28)#012#18 0x00007f8d3b4ff023 g_main_context_iteration (libglib-2.0.so.0 + 0x53023)#012#19 0x00007f8d3b2af27d g_application_run (libgio-2.0.so.0 + 0xdc27d)#012#20 0x00007f8d3c5b9249 ffi_call_unix64 (libffi.so.8 + 0x7249)#012#21 0x00007f8d3c5b8639 ffi_call_int (libffi.so.8 + 0x6639)#012#22 0x00007f8d3b6293e2 n/a (_gi.cpython-39-x86_64-linux-gnu.so + 0x273e2)#012#23 0x00007f8d3b62ce16 n/a (_gi.cpython-39-x86_64-linux-gnu.so + 0x2ae16)#012#24 0x00000000005407b1 PyObject_Call (python3.9 + 0x1407b1)#012#25 0x00000000005181b6 _PyEval_EvalFrameDefault (python3.9 + 0x1181b6)#012#26 0x0000000000514a75 n/a (python3.9 + 0x114a75)#012#27 0x000000000052d302 _PyFunction_Vectorcall (python3.9 + 0x12d302)#012#28 0x0000000000516543 _PyEval_EvalFrameDefault (python3.9 + 0x116543)#012#29 0x0000000000514a75 n/a (python3.9 + 0x114a75)#012#30 0x000000000051480b _PyEval_EvalCodeWithName (python3.9 + 0x11480b)#012#31 0x00000000005fb257 PyEval_EvalCode (python3.9 + 0x1fb257)#012#32 0x00000000006205fb n/a (python3.9 + 0x2205fb)#012#33 0x000000000061b724 n/a (python3.9 + 0x21b724)#012#34 0x000000000061fb2d n/a (python3.9 + 0x21fb2d)#012#35 0x000000000061f63a PyRun_SimpleFileExFlags (python3.9 + 0x21f63a)#012#36 0x0000000000613527 Py_RunMain (python3.9 + 0x213527)#012#37 0x00000000005ef7fd Py_BytesMain (python3.9 + 0x1ef7fd)#012#38 0x00007f8d3c216565 __libc_start_main (libc.so.6 + 0x28565)#012#39 0x00000000005ef6fe _start (python3.9 + 0x1ef6fe)#012#012Stack trace of thread 17466:#012#0  0x00007f8d3c2fa22f __GI___poll (libc.so.6 + 0x10c22f)#012#1  0x00007f8d3b554cc6 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa8cc6)#012#2  0x00007f8d3b4ff023 g_main_context_iteration (libglib-2.0.so.0 + 0x53023)#012#3  0x00007f8d3a704f9d dconf_gdbus_worker_thread (libdconfsettings.so + 0xaf9d)#012#4  0x00007f8d3b52f901 g_thread_proxy (libglib-2.0.so.0 + 0x83901)#012#5  0x00007f8d3c3e5450 start_thread (libpthread.so.0 + 0x9450)#012#6  0x00007f8d3c305d53 __clone (libc.so.6 + 0x117d53)#012#012Stack trace of thread 17487:#012#0  0x00007f8d3c3f231e __futex_abstimed_wait_common64 (libpthread.so.0 + 0x1631e)#012#1  0x00007f8d3c3eb540 __pthread_cond_wait_common (libpthread.so.0 + 0xf540)#012#2  0x00007f8c8d8ef29b n/a (radeonsi_dri.so + 0x15229b)#012#3  0x00007f8c8d8e8e2b n/a (radeonsi_dri.so + 0x14be2b)#012#4  0x00007f8d3c3e5450 start_thread (libpthread.so.0 + 0x9450)#012#5  0x00007f8d3c305d53 __clone (libc.so.6 + 0x117d53)#012#012Stack trace of thread 17464:#012#0  0x00007f8d3c2fff6d syscall (libc.so.6 + 0x111f6d)#012#1  0x00007f8d3b54f2dc g_cond_wait_until (libglib-2.0.so.0 + 0xa32dc)#012#2  0x00007f8d3b4d13e1 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x253e1)#012#3  0x00007f8d3b5325ea g_thread_pool_thread_proxy.lto_priv.0 (libglib-2.0.so.0 + 0x865ea)#012#4  0x00007f8d3b52f901 g_thread_proxy (libglib-2.0.so.0 + 0x83901)#012#5  0x00007f8d3c3e5450 start_thread (libpthread.so.0 + 0x9450)#012#6  0x00007f8d3c305d53 __clone (libc.so.6 + 0x117d53)#012#012Stack trace of thread 17469:#012#0  0x00007f8d3c2fa22f __GI___poll (libc.so.6 + 0x10c22f)#012#1  0x00007f8d3b554cc6 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa8cc6)#012#2  0x00007f8d3b500e53 g_main_loop_run (libglib-2.0.so.0 + 0x54e53)#012#3  0x00007f8d2accbe60 _ZN3WTF7RunLoop3runEv (libjavascriptcoregtk-4.0.so.18 + 0x153ce60)#012#4  0x00007f8d2ac7d6bd _ZNK3WTF8FunctionIFvvEEclEv (libjavascriptcoregtk-4.0.so.18 + 0x14ee6bd)#012#5  0x00007f8d2acce2fd wtfThreadEntryPoint (libjavascriptcoregtk-4.0.so.18 + 0x153f2fd)#012#6  0x00007f8d3c3e5450 start_thread (libpthread.so.0 + 0x9450)#012#7  0x00007f8d3c305d53 __clone (libc.so.6 + 0x117d53)#012#012Stack trace of thread 17490:#012#0  0x00007f8d3c3f231e __futex_abstimed_wait_common64 (libpthread.so.0 + 0x1631e)#012#1  0x00007f8d3c3eb540 __pthread_cond_wait_common (libpthread.so.0 + 0xf540)#012#2  0x00007f8c8d8ef29b n/a (radeonsi_dri.so + 0x15229b)#012#3  0x00007f8c8d8e8e2b n/a (radeonsi_dri.so + 0x14be2b)#012#4  0x00007f8d3c3e5450 start_thread (libpthread.so.0 + 0x9450)#012#5  0x00007f8d3c305d53 __clone (libc.so.6 + 0x117d53)#012#012Stack trace of thread 17471:#012#0  0x00007f8d3c2fa22f __GI___poll (libc.so.6 + 0x10c22f)#012#1  0x00007f8d3b554cc6 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa8cc6)#012#2  0x00007f8d3b500e53 g_main_loop_run (libglib-2.0.so.0 + 0x54e53)#012#3  0x00007f8d2accbe60 _ZN3WTF7RunLoop3runEv (libjavascriptcoregtk-4.0.so.18 + 0x153ce60)#012#4  0x00007f8d2ac7d6bd _ZNK3WTF8FunctionIFvvEEclEv (libjavascriptcoregtk-4.0.so.18 + 0x14ee6bd)#012#5  0x00007f8d2acce2fd wtfThreadEntryPoint (libjavascriptcoregtk-4.0.so.18 + 0x153f2fd)#012#6  0x00007f8d3c3e5450 start_thread (libpthread.so.0 + 0x9450)#012#7  0x00007f8d3c305d53 __clone (libc.so.6 + 0x117d53)#012#012Stack trace of thread 17492:#012#0  0x00007f8d3c3f231e __futex_abstimed_wait_common64 (libpthread.so.0 + 0x1631e)#012#1  0x00007f8d3c3eb540 __pthread_cond_wait_common (libpthread.so.0 + 0xf540)#012#2  0x00007f8c8d8ef29b n/a (radeonsi_dri.so + 0x15229b)#012#3  0x00007f8c8d8e8e2b n/a (radeonsi_dri.so + 0x14be2b)#012#4  0x00007f8d3c3e5450 start_thread (libpthread.so.0 + 0x9450)#012#5  0x00007f8d3c305d53 __clone (libc.so.6 + 0x117d53)#012#012Stack trace of thread 17477:#012#0  0x00007f8d3c2fa22f __GI___poll (libc.so.6 + 0x10c22f)#012#1  0x00007f8d3b554cc6 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa8cc6)#012#2  0x00007f8d3b500e53 g_main_loop_run (libglib-2.0.so.0 + 0x54e53)#012#3  0x00007f8d2accbe60 _ZN3WTF7RunLoop3runEv (libjavascriptcoregtk-4.0.so.18 + 0x153ce60)#012#4  0x00007f8d2ac7d6bd _ZNK3WTF8FunctionIFvvEEclEv (libjavascriptcoregtk-4.0.so.18 + 0x14ee6bd)#012#5  0x00007f8d2acce2fd wtfThreadEntryPoint (libjavascriptcoregtk-4.0.so.18 + 0x153f2fd)#012#6  0x00007f8d3c3e5450 start_thread (libpthread.so.0 + 0x9450)#012#7  0x00007f8d3c305d53 __clone (libc.so.6 + 0x117d53)#012#012Stack trace of thread 17473:#012#0  0x00007f8d3c2fa22f __GI___poll (libc.so.6 + 0x10c22f)#012#1  0x00007f8d3b554cc6 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa8cc6)#012#2  0x00007f8d3b500e53 g_main_loop_run (libglib-2.0.so.0 + 0

[LJoris]

Created attachment 445331 [details]
eolie backtrace 17461

[Michael Catanzaro]

(In reply to LJoris from comment #12)
> the syslog output from eolie, paired with a backtrace should this help

That's hard to read, but the backtrace is very useful. That is a *third* crash, the at-spi2-atk issue I mentioned earlier. To keep the bug reports readable, I really need to insist on a separate bug report for each crash. Currently we have:

 * This bug for the original Nicosia::GCGLLayer::makeContextCurrent issue
 * Unrelated WebKitWebsiteDataStore crash (comment #6), needs a separate WebKit bug report
 * Unrelated accessibility crash (comment #13), needs a separate WebKit bug report *and* and at-spi2-atk bug report. Definitely an at-spi2-atk bug here, *probably* also a WebKit bug. (Not sure.)
 * A fourth unrelated crash after receiving an X server error (https://gitlab.gnome.org/GNOME/epiphany/-/issues/1642#note_1317772, probably a mesa bug, no backtrace for this one yet)

It's a lot of bugs. This might be a record: you must be very unlucky!

Anyway, at least now with good backtraces you have enough to prove there are real bugs, so we are making some progress.

[LJoris]

I'll see what i can do.

Note the i'm also learning how to distinguish the different bugs. For now i only distinguish by looking at EXE.

I'm not affected by these bugs, only whatever dares to work with Webkit is.

[LJoris]

Since my last post i've had repeat system freezes whenever an animated gif plays  in the epiphany browser.

There is no coredump generated and i don't know how i could generate any thing useful when reproducing this event. Since it is reproducible by playing an animated GIF i'm willing to spend more time on this but i need to know what to do to collect meaningful data.

[LJoris]

checksec --proc=epiphany

* System-wide ASLR (kernel.randomize_va_space): Full (Setting: 2)

  Description - Make the addresses of mmap base, heap, stack and VDSO page randomized.
  This, among other things, implies that shared libraries will be loaded to random 
  addresses. Also for PIE-linked binaries, the location of code start is randomized.

  See the kernel file 'Documentation/sysctl/kernel.txt' for more details.

* Does the CPU support NX: Yes

         COMMAND    PID RELRO           STACK CANARY            SECCOMP          NX/PaX        PIE                     FORTIFY
        epiphany 119202 Full RELRO      Canary found            No Seccomp       NX enabled    PIE enabled             No

[Michael Catanzaro]

So your distro builds it with hardening flags. Great. Totally irrelevant to this issue.

[LJoris]

The reason i shared the checksec output was to show what is the context for this and the other issue reported should that matter with interpreting backtrace information.


In the meantime I've ran an exhaustive memory integrity check. No test failed, no warnings of any kind were reported.

[LJoris]

At this point i notice 'some' improvement in that the system freeze is less accute. Web/Epiphany freezes but now the numlock remains responsive which was not the case before. I'm not certain what to attribute this improvement to.

the animated gifs now appear to play well but when video plays (with sound?) the system still freezes