Bug 249844

Summary: [GTK] Uploading any media uses too much memory
Product: WebKit Reporter: Tiago d'Almeida <tjamadeira>
Component: WebKitGTKAssignee: Carlos Garcia Campos <cgarcia>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, mcatanzaro, philn, tjamadeira
Priority: P2    
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Debug Log
none
Output Log
none
Memory usage during debuging
none
Memory usage after
none
GST.log
none
Video of Memory Usage
none
Dialog Screenshot
none
GDB pasted output
none
GDB results
none
Massif dump when uploading a 16 seconds mp4 video
none
screenshot
none
with PR, bump gone none

Description Tiago d'Almeida 2022-12-23 06:59:14 PST
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!
Comment 1 Tiago d'Almeida 2022-12-23 06:59:49 PST
Created attachment 464176 [details]
Output Log
Comment 2 Tiago d'Almeida 2022-12-23 07:00:40 PST
Maybe related with https://bugs.webkit.org/show_bug.cgi?id=89622
Comment 3 Tiago d'Almeida 2022-12-23 07:09:32 PST
Created attachment 464177 [details]
Memory usage during debuging
Comment 4 Tiago d'Almeida 2022-12-23 07:12:04 PST
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.
Comment 5 Sam Sneddon [:gsnedders] 2022-12-24 09:25:57 PST
(I'm assuming this is something in the platform/port layer, as this doesn't reproduce on Apple's macOS port)
Comment 6 Tiago d'Almeida 2022-12-25 08:47:26 PST
Yes, maybe that is, because I haven't iOS/iPhone to test it ...
Comment 7 Philippe Normand 2022-12-29 03:44:22 PST
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/
Comment 8 Tiago d'Almeida 2023-01-02 04:35:27 PST
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/user@1000.service/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
Comment 9 Tiago d'Almeida 2023-01-02 04:37:48 PST
Created attachment 464288 [details]
GST.log
Comment 10 Tiago d'Almeida 2023-01-02 04:38:49 PST
Created attachment 464289 [details]
Video of Memory Usage
Comment 11 Philippe Normand 2023-01-02 09:40:24 PST
Is this also happening with webm/vp9 or vp8 videos?
Comment 12 Tiago d'Almeida 2023-01-02 10:52:02 PST
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.
Comment 13 Tiago d'Almeida 2023-01-02 10:52:41 PST
Created attachment 464294 [details]
Dialog Screenshot
Comment 14 Philippe Normand 2023-01-03 01:08:26 PST
Sorry but without massif or heaptrack reports I don't think I can do much...
Comment 15 Tiago d'Almeida 2023-01-05 09:51:01 PST
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
Comment 16 Tiago d'Almeida 2023-01-05 09:51:33 PST
Created attachment 464353 [details]
GDB pasted output
Comment 17 Philippe Normand 2023-01-05 10:06:55 PST
Not useful... It looks like this is a failed analysis of a crashed packagekit process.
Comment 18 Michael Catanzaro 2023-01-05 10:21:49 PST
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. ;)
Comment 19 Tiago d'Almeida 2023-01-05 10:56:13 PST
It seems this bug is opening other bugs as well ...

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

https://github.com/PackageKit/PackageKit/issues/595
Comment 20 Tiago d'Almeida 2023-01-05 11:21:09 PST
https://github.com/sonnyp/Tangram/issues/185
Comment 21 Tiago d'Almeida 2023-01-05 11:27:09 PST
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)
Comment 22 Tiago d'Almeida 2023-01-05 11:27:38 PST
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)
Comment 23 Michael Catanzaro 2023-01-05 16:20:05 PST
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.
Comment 24 Tiago d'Almeida 2023-02-10 15:19:33 PST
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.
Comment 25 Tiago d'Almeida 2023-02-10 15:20:23 PST
Created attachment 464948 [details]
GDB results
Comment 26 Philippe Normand 2023-02-11 02:36:15 PST
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.
Comment 27 Philippe Normand 2023-02-13 02:14:25 PST
Created attachment 464970 [details]
Massif dump when uploading a 16 seconds mp4 video
Comment 28 Philippe Normand 2023-02-13 02:15:22 PST
Created attachment 464971 [details]
screenshot

That is one big string...
Comment 29 Carlos Garcia Campos 2023-02-13 04:26:14 PST
Pull request: https://github.com/WebKit/WebKit/pull/10029
Comment 30 Carlos Garcia Campos 2023-02-13 04:26:49 PST
(In reply to Carlos Garcia Campos from comment #29)
> Pull request: https://github.com/WebKit/WebKit/pull/10029

Could you try with this PR?
Comment 31 Philippe Normand 2023-02-13 04:51:17 PST
Created attachment 464972 [details]
with PR, bump gone
Comment 32 EWS 2023-02-14 05:12:48 PST
Committed 260252@main (ff7c48892878): <https://commits.webkit.org/260252@main>

Reviewed commits have been landed. Closing PR #10029 and removing active labels.
Comment 33 Tiago d'Almeida 2023-02-16 13:07:50 PST
What a bug!

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

Thank you to all of you!
Comment 34 Michael Catanzaro 2023-02-16 13:22:23 PST
But... the change is not in TP yet. ;)