Bug 240026 – [GTK] Page crashed

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Tiago d'Almeida]

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.

[Tiago d'Almeida]

Also, in big conversations the web browser became unresponsive.

[Michael Catanzaro]

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).

[Philippe Normand]

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.

[Philippe Normand]

Tangram 1.4.2 plays whatsapp audios fine here.

[Tiago d'Almeida]

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.

[Tiago d'Almeida]

Created attachment 458949 [details]
Flatpak Coredump

[Tiago d'Almeida]

Created attachment 458950 [details]
Flatpak Run with Exported Vars

[Tiago d'Almeida]

Created attachment 458951 [details]
GDB log file

[Tiago d'Almeida]

(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 ... :)

[Michael Catanzaro]

> 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.

[Tiago d'Almeida]

> 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

[Tiago d'Almeida]

Created attachment 458953 [details]
Flatpak Run with Exported Vars

[Tiago d'Almeida]

Created attachment 458954 [details]
GST log

[Philippe Normand]

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

[Tiago d'Almeida]

(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!

[Philippe Normand]

Well, it'd be good to have a good gdb crash dump first :) Did you install org.webkit.Sdk.Debug ?

[Philippe Normand]

sorry typo, org.gnome.Sdk.Debug

[Michael Catanzaro]

(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

[Tiago d'Almeida]

(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.

[Tiago d'Almeida]

This bug report can be closed, because the problem is resolved.