Hello! I've tested this to many times, so I'm filling this bug ... The web.whatsapp.com web app, crashes when the conversation have some kind of video and/or many images. This do not happen in google chrome. The two programs that I see the bug: epiphany --version Web 41.4 Tangram - Browser for your pinned tabs ID: re.sonny.Tangram Ref: app/re.sonny.Tangram/x86_64/stable Arch: x86_64 Branch: stable Version: 1.4.2 License: GPL-3.0+ Origin: flathub Collection: org.flathub.Stable Installation: system Installed: 159,7 kB Runtime: org.gnome.Platform/x86_64/42 Sdk: org.gnome.Sdk/x86_64/42 Commit: 6da4c8b0194209b590bf7e9565f767c5b2d6897b3c3690ada8634bf31d6205a2 Parent: 0a8c5c17110dfc6a61d7c1acac0d14b761e4bd34181334f04579466e8c1896b2 Subject: v1.4.2 (524df5bb) Date: 2022-04-23 10:56:25 +0000 What I tested so far: - Clean cookies; - Clean storage; - Close tab; - Restart browser; - Reboot computer. I've tried to contact Whatsapp, but with no success ... If this issue do not make sense for you, please tell me what to do. Thanks in advance.
Also, in big conversations the web browser became unresponsive.
Please attach a backtrace taken with gdb. See https://blogs.gnome.org/mcatanzaro/2021/09/18/creating-quality-backtraces-for-crash-reports/ if you need instructions (including flatpak instructions near the bottom).
Can you provide a log please? Set these env vars before calling the app: export GST_DEBUG="3,webkit*:6" export GST_DEBUG_FILE=gst.log Then attach gst.log here, compressed if possible.
Tangram 1.4.2 plays whatsapp audios fine here.
Thanks for your help! Here there are the comands that I executed (and some terminal logs): export GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 flatpak-coredumpctl re.sonny.Tangram flatpak run re.sonny.Tangram No gst.log file created. If I missed some command, tell me, please.
Created attachment 458949 [details] Flatpak Coredump
Created attachment 458950 [details] Flatpak Run with Exported Vars
Created attachment 458951 [details] GDB log file
(In reply to Michael Catanzaro from comment #2) > Please attach a backtrace taken with gdb. See > https://blogs.gnome.org/mcatanzaro/2021/09/18/creating-quality-backtraces- > for-crash-reports/ if you need instructions (including flatpak instructions > near the bottom). Also, what a good article! I put in practice that systemd-coredump recommendation. Just a note, in Fedora 35, the man 5 coredump.conf page says that is better to create a drop-in file in a /etc/systemd/coredump.conf.d/ folder than in the /etc/systemd/systemd.conf.d May be will be good to correct this in your article ... :)
> No gst.log file created. It's going to be created inside the flatpak sandbox. Use 'flatpak run --filesystem=home' to avoid this. > Just a note, in Fedora 35, the man 5 coredump.conf page says that is better to create a drop-in file in a /etc/systemd/coredump.conf.d/ folder than in the /etc/systemd/systemd.conf.d May be will be good to correct this in your article ... :) Indeed, thanks for the feedback.
> Indeed, thanks for the feedback. You're welcome! --- Sorry, but I needed to add another exported var to create a gst.lof file: export GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_FORCE_SANDBOX=0 flatpak run --filesystem=home re.sonny.Tangram
Created attachment 458953 [details] Flatpak Run with Exported Vars
Created attachment 458954 [details] GST log
There we go again, hello old openh264dec friend: WARN openh264dec gstopenh264dec.cpp:342:gst_openh264dec_handle_frame:<openh264dec0> Failed to look up frame ref 5
(In reply to Philippe Normand from comment #14) > There we go again, hello old openh264dec friend: > > WARN openh264dec > gstopenh264dec.cpp:342:gst_openh264dec_handle_frame:<openh264dec0> Failed to > look up frame ref 5 Wow! Did we find the bug? What a amazing thing!
Well, it'd be good to have a good gdb crash dump first :) Did you install org.webkit.Sdk.Debug ?
sorry typo, org.gnome.Sdk.Debug
(In reply to Tiago d'Almeida from comment #15) > Did we find the bug? What a amazing thing! When you provide logs, Phil finds bugs. It's kinda his thing. Sadly, OpenH264 bugs are rarely fixed. Anecdotally, OpenH264 2.2.0 (which recently reached Fedora) seems to play video better than 2.1.0 (the version still used by flatpaks). Maybe an update would help: https://gitlab.com/freedesktop-sdk/openh264-extension/-/merge_requests/31
(In reply to Philippe Normand from comment #17) > sorry typo, org.gnome.Sdk.Debug Yes: flatpak install org.gnome.Sdk//42 flatpak install org.gnome.Sdk.Debug//42
Created attachment 459002 [details] Tangram 1.4.2 with WebKitGTK 2.36.1 I'm also able to trigger a media crash with Tangram 1.4.2 and WebKitGTK 2.36.1. It doesn't trigger always with the exact same conversation with the loading GIF, but in ~70% of my tests.
This bug report can be closed, because the problem is resolved.