Actually it's not the "top" of the output that's interesting. The
snapshot #1 just shows where memory went initially on start-up (to
loading images). That doesn't represent the ongoing growth problem
though. You need to scroll down to later snapshots in the ms_print
output to see where the growth is coming from, like snapshot 51:

 47 68,075,238,605       72,060,280       63,908,218     8,152,062            0
 48 70,175,452,080       73,101,400       64,835,851     8,265,549            0
 49 71,750,692,416       74,288,744       65,927,330     8,361,414            0
 50 72,800,335,769       75,355,616       66,877,167     8,478,449            0
 51 73,849,979,162       81,425,416       72,853,026     8,572,390            0
89.47% (72,853,026B) (heap allocation functions) malloc/new/new[], --alloc-fns, 
etc.
->19.72% (16,059,766B) 0x58BF577: g_malloc (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
| ->17.59% (14,320,777B) 0x58D70F4: g_slice_alloc (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
| | ->13.29% (10,825,417B) 0x58D7587: g_slice_alloc0 (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
| | | ->05.48% (4,459,320B) 0x564F7E4: g_type_create_instance (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1)
| | | | ->04.96% (4,040,752B) 0x5630096: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1)
| | | | | ->04.84% (3,937,672B) 0x6C05829: ??? (in 
/usr/lib/x86_64-linux-gnu/mutter/libmutter-clutter-1.so)
| | | | | | ->04.55% (3,708,152B) 0x5630CF5: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1)
| | | | | | | ->02.97% (2,417,720B) 0x5631FBC: g_object_newv (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1)
| | | | | | | | ->02.97% (2,417,720B) 0x6911B0C: ??? (in 
/usr/lib/libgjs.so.0.0.0)
| | | | | | | |   ->02.97% (2,417,720B) 0xE0BBD5B: ??? (in 
/usr/lib/x86_64-linux-gnu/libmozjs-52.so.0.0.0)
| | | | | | | |     ->02.97% (2,417,720B) 0xE0BBF87: ??? (in 
/usr/lib/x86_64-linux-gnu/libmozjs-52.so.0.0.0)
| | | | | | | |       ->02.97% (2,417,720B) 0xDF51842: 
JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, 
JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (in 
/usr/lib/x86_64-linux-gnu/libmozjs-52.so.0.0.0)
| | | | | | | |         ->02.97% (2,417,720B) 0x692B2A4: 
gjs_call_function_value (in /usr/lib/libgjs.so.0.0.0)
| | | | | | | |           ->02.97% (2,417,720B) 0x6910454: ??? (in 
/usr/lib/libgjs.so.0.0.0)

So you then need debug symbols for libraries like:
  /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1
  /usr/lib/x86_64-linux-gnu/mutter/libmutter-clutter-1.so
  /usr/lib/libgjs.so.0.0.0
  /usr/lib/x86_64-linux-gnu/libmozjs-52.so.0.0.0

Which sounds like it's getting closer to the core of the problem.

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-shell in Ubuntu.
https://bugs.launchpad.net/bugs/1672297

Title:
  gnome-shell uses lots of memory, and grows over time

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1672297/+subscriptions

-- 
desktop-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

Reply via email to