When viewing JS/CSS example https://codepen.io/anon/embed/rNMprwo ( first example from https://css-tricks.com/how-to-play-and-pause-css-animations-with-css-custom-properties/ ) using WPE/cog on i.MX8M with Weston 12.0.y , the WPE process grows by some 1 MiB every minute. Eventually, the system would run out of memory and the WPE process is stopped using OOM . Invocation is ' $ cog https://codepen.io/anon/embed/rNMprwo ' This happens with both WPE 2.40.5 from meta-webkit as well as recent e99d13b4e5e1 ("[WGSL] Add validation to integer modulo https://bugs.webkit.org/show_bug.cgi?id=264603 rdar://118239748") . I am not able to reproduce it with matching desktop WebkitGTK builds. Currently I am looking for a way to narrow the leak down, is there some tool for that purpose that would be part of Webkit ?
Furthermore, mesa 23.2.1 (etnaviv driver, so gles2), Linux 6.1.62 (mainline + a couple of DT patches).
> Currently I am looking for a way to narrow the leak down, is there some tool for that purpose that would be part of Webkit ? I'm not aware of specific tooling for this. Would be nice to have though!
I understand people generally try to debug such issues using sysprof, or maybe massif. (That said, I don't think I've ever successfully debugged an issue like this ever, so....)
This turned out to be a memory leak in Cairo 1.16.y , fixed in 1.18.y , see https://gitlab.freedesktop.org/cairo/cairo/-/issues/805 and similar fixes in the Cairo git tree. Thanks for all the input. Massif helped narrow it down in the end. Resolved . For future reference: $ valgrind --tool=massif --depth=8 --trace-children=yes cog http://link ... $ ms_print massif.out.20 -------------------------------------------------------------------------------- Command: /usr/libexec/wpe-webkit-1.1/WPEWebProcess 10 24 Massif arguments: --depth=8 ms_print arguments: massif.out.20 -------------------------------------------------------------------------------- MB 121.2^ # | @@@# | :@@@@@# | @@@:::@@@@@# | :::@@ :::@@@@@# | @:@@:: @@ :::@@@@@# | :@@:@:@ :: @@ :::@@@@@# | @@@@::@ :@:@ :: @@ :::@@@@@# | :::@@ @::@ :@:@ :: @@ :::@@@@@# | :::::::@@ @::@ :@:@ :: @@ :::@@@@@# | ::::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# | @::::: ::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# | :::@: ::: ::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# | @:::::: @: ::: ::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# | @::@::: :: @: ::: ::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# | @@@:@: @::: :: @: ::: ::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# | @@::@@ :@: @::: :: @: ::: ::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# | :::::@ : @@ :@: @::: :: @: ::: ::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# | :::: :::@ : @@ :@: @::: :: @: ::: ::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# | : :: :::@ : @@ :@: @::: :: @: ::: ::: : :::@@ @::@ :@:@ :: @@ :::@@@@@# 0 +----------------------------------------------------------------------->Ti 0 1.022 ... 74.04% (21,015,725B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. ->31.00% (8,799,962B) 0x9F5CDFD: strdup (strdup.c:42) | ->20.62% (5,851,900B) 0xA0CA5C3: _cairo_font_options_init_copy (cairo-font-options.c:90) | | ->10.31% (2,925,825B) 0xA105792: _cairo_scaled_font_init_key (cairo-scaled-font.c:665) | | | ->10.31% (2,925,825B) 0xA105792: cairo_scaled_font_create (cairo-scaled-font.c:1064) ...