Bug 249844 – [GTK] Uploading any media uses too much memory

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Tiago d'Almeida]

Created attachment 464175 [details]
Debug Log

Hello!

When I try to upload some media via Whastapp Web, the program uses too much memory until the computer stays without memory at all!

With uploading images, this do not occur with so much memory pressure.
With videos, I need to open Whatsapp Web in Google Chrome (I tested with 4GB normal memory and 4GB zram memory - I have 8gb of memory).

I tested in Tangram and GNOME Web. This dos not happen in Google Chrome.

Fedora 37
Web 43.0
Tangram 1.4.2

The debug comands that I used:

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

If there is some other debug method and/or command to use, tell me!

[Tiago d'Almeida]

Created attachment 464176 [details]
Output Log

[Tiago d'Almeida]

Maybe related with https://bugs.webkit.org/show_bug.cgi?id=89622

[Tiago d'Almeida]

Created attachment 464177 [details]
Memory usage during debuging

[Tiago d'Almeida]

Created attachment 464178 [details]
Memory usage after

The tangram program didn't stop "thinking" and the memory going up, so I close it.

This photo is to show you the memory difference during and after the program working.

[Sam Sneddon [:gsnedders]]

(I'm assuming this is something in the platform/port layer, as this doesn't reproduce on Apple's macOS port)

[Tiago d'Almeida]

Yes, maybe that is, because I haven't iOS/iPhone to test it ...

[Philippe Normand]

can you set this env var: G_DEBUG=fatal_criticals

and then after tangram crashed, get a trace, as explained in https://www.figuiere.net/technotes/notes/tn001/

[Tiago d'Almeida]

flatpak info re.sonny.Tangram

Version: 1.4.2
Sdk: org.gnome.Sdk/x86_64/42

======================

flatpak install org.gnome.Sdk.Debug//42
flatpak install re.sonny.Tangram.Debug

Note: the commands above with "--user" gives this error:
> Error: No remote refs found for ‘org.gnome.Sdk.Debug//42’
Maybe, updating your article?

======================

export GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_FORCE_SANDBOX=0 G_DEBUG=fatal_criticals

flatpak-coredumpctl re.sonny.Tangram

Immediate error raised:

Version-Release number of selected component:
flatpak-1.14.1-1.fc37

Additional info:
reporter:       libreport-2.17.4
cgroup:         0::/user.slice/user-1000.slice/[e-mail]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-787a9a27-74c3-4fb9-be11-71a6a2550753.scope
cmdline:        /usr/bin/python3 /usr/bin/flatpak-coredumpctl re.sonny.Tangram
crash_function: check_call
exception_type: subprocess.CalledProcessError
executable:     /usr/bin/flatpak-coredumpctl
interpreter:    python3-3.11.1-1.fc37.x86_64
kernel:         6.0.15-300.fc37.x86_64
runlevel:       N 5
type:           Python3
uid:            1000

Truncated backtrace:
subprocess.py:413:check_call:subprocess.CalledProcessError: Command '['coredumpctl', 'dump']' returned non-zero exit status 1.

Traceback (most recent call last):
  File "/usr/bin/flatpak-coredumpctl", line 83, in <module>
    coredumper.run()
  File "/usr/bin/flatpak-coredumpctl", line 44, in run
    subprocess.check_call(["coredumpctl", "dump"] + shlex.split(self.coredumpctl_matches),
  File "/usr/lib64/python3.11/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['coredumpctl', 'dump']' returned non-zero exit status 1.

Local variables in innermost frame:
popenargs: (['coredumpctl', 'dump'],)
kwargs: {'stdout': <tempfile._TemporaryFileWrapper object at 0x7feb692fd410>, 'stderr': <tempfile._TemporaryFileWrapper object at 0x7feb690dc7d0>}
retcode: 1
cmd: ['coredumpctl', 'dump']

For more info, see this issue: https://bugzilla.redhat.com/show_bug.cgi?Bugzilla_restrictlogin=on&id=2157626

======================

export GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_FORCE_SANDBOX=0 G_DEBUG=fatal_criticals

flatpak run --filesystem=home re.sonny.Tangram

Error after I clicked in the "Attach Photos/Videos" in Whatsapp Web.

Output:

** (process:88464): WARNING **: 12:30:35.722: Error writing credentials to socket: Erro ao enviar a mensagem: Túnel quebrado
Gjs-Message: 12:30:35.913: JS LOG: gjs 1.72.3
Gjs-Message: 12:30:35.913: JS LOG: WebKitGTK 2.38.3
Gjs-Message: 12:30:35.913: JS LOG: libsoup 2.74.3
Gjs-Message: 12:30:35.913: JS LOG: env: flatpak
Gjs-Message: 12:30:35.913: JS LOG: data_dir: /home/.../.var/app/re.sonny.Tangram/data/Tangram
Gjs-Message: 12:30:35.913: JS LOG: cache_dir: /home/.../.var/app/re.sonny.Tangram/cache/Tangram
Gjs-Message: 12:30:35.913: JS LOG: config_dir: /home/.../.var/app/re.sonny.Tangram/config/Tangram
Gjs-Message: 12:30:35.913: JS LOG: applications_dir: /home/.../.local/share/applications
Gjs-Message: 12:30:35.913: JS LOG: keyfile_settings_path: 
Gjs-Message: 12:30:35.928: JS LOG: programInvocationName: /app/bin/re.sonny.Tangram
Gjs-Message: 12:30:35.928: JS LOG: _: null
Gjs-Message: 12:30:35.930: JS LOG: argv /app/bin/re.sonny.Tangram

(re.sonny.Tangram:2): GLib-CRITICAL **: 12:32:58.292: g_variant_new_string: assertion 'string != NULL' failed

[Tiago d'Almeida]

Created attachment 464288 [details]
GST.log

[Tiago d'Almeida]

Created attachment 464289 [details]
Video of Memory Usage

[Philippe Normand]

Is this also happening with webm/vp9 or vp8 videos?

[Tiago d'Almeida]

It do not let me choose the image/video type. So, that media files can't be choosen.

In the screenshoot, the dialog do not show the recorder webm file I have.

[Tiago d'Almeida]

Created attachment 464294 [details]
Dialog Screenshot

[Philippe Normand]

Sorry but without massif or heaptrack reports I don't think I can do much...

[Tiago d'Almeida]

I tried again, and there is here the results. I hope this will be helpfull ...

export GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_FORCE_SANDBOX=0 G_DEBUG=fatal_criticals

*sudo* flatpak-coredumpctl re.sonny.Tangram

[Tiago d'Almeida]

Created attachment 464353 [details]
GDB pasted output

[Philippe Normand]

Not useful... It looks like this is a failed analysis of a crashed packagekit process.

[Michael Catanzaro]

You'll need to run coredumpctl, find the pid of the WebKit process that crashed, then if it's pid 12345, run `flatpak-coredumpctl -m 12345 re.sonny.Tangram`. Without -m it will open the most recent crash.

Seems like you could report a separate bug to PackageKit too. Software is generally not supposed to crash. ;)

[Tiago d'Almeida]

It seems this bug is opening other bugs as well ...

https://github.com/flatpak/flatpak/issues/5244

https://github.com/PackageKit/PackageKit/issues/595

[Tiago d'Almeida]

https://github.com/sonnyp/Tangram/issues/185

[Tiago d'Almeida]

While I'm waiting or response from that issues, I tried to reproduce the issue in GNOME Web, but after a while the page is not responding.

How can we debug that?

epiphany --version                                                                                                                           
Web 43.0
(dnf installed, not from flatpak)

[Tiago d'Almeida]

While I'm waiting or response from that issues, I tried to reproduce the issue in GNOME Web, but after a while the page is not responding.

How can we debug that?

epiphany --version                                                                                                                           
Web 43.0
(dnf installed, not from flatpak)

[Michael Catanzaro]

Let's take a step back. Please run 'coredumpctl' and paste the last few lines here, so we can see exactly what state you're in. The commands you gave in flatpak#5244 only make sense if the tangram crash is the most recent crash.

[Tiago d'Almeida]

Sorry, for my late answer.

This issue still happens in Web. I tried to test it and get some debug but I can't.

This time I run:

>>> prlimit --rss=1024:2048 --memlock=1024:2048 epiphany
Warning: using insecure memory!
^C
(epiphany:296027): epiphany-WARNING **: 20:00:53.053: Processo Web falhou fatalmente

Even with this RAM limit, the app uses all memory available until my PC shuts the GNOME session down.

> About the "coredumpctl"

No message about this app today (when I tried again debugging).

> epiphany --version 43.0 rpm/dnf Fedora 37 updated

Forgeting tangram for a while, which command I can test this?

I tried `gdb` but without success, as you can see in the file attached.

[Tiago d'Almeida]

Created attachment 464948 [details]
GDB results

[Philippe Normand]

Can you check with Web Tech Preview please?

I was able to reproduce this in Tangram (using WebKitGTK 2.38 under the hood) but not with a MiniBrowser build from WebKit main.

I suspect this might be a duplicate bug of the ImageDecoder deadlock that was fixed recently.

[Philippe Normand]

Created attachment 464970 [details]
Massif dump when uploading a 16 seconds mp4 video

[Philippe Normand]

Created attachment 464971 [details]
screenshot

That is one big string...

[Carlos Garcia Campos]

Pull request: https://github.com/WebKit/WebKit/pull/10029

[Carlos Garcia Campos]

(In reply to Carlos Garcia Campos from comment #29)
> Pull request: https://github.com/WebKit/WebKit/pull/10029

Could you try with this PR?

[Philippe Normand]

Created attachment 464972 [details]
with PR, bump gone

[EWS]

Committed 260252@main (ff7c48892878): <https://commits.webkit.org/260252@main>

Reviewed commits have been landed. Closing PR #10029 and removing active labels.

[Tiago d'Almeida]

What a bug!

I tested right now with Epiphany Preview (nightly) and the bug is gone!

Thank you to all of you!

[Michael Catanzaro]

But... the change is not in TP yet. ;)