unity8 leaking memory on idle phone

[Colin Ian King]

I've found that on an idle phone, unity8 is very slowly consuming more heap at around 1K every 15-20 minutes. I ran my analysis over 12 hours and found that there are brk()s occurring roughly every 10 minutes and the heap is just increasing in size and never shrinking, indicating a small memory leak.

gdb shows:

(gdb) where
#0 __brk (addr=0x31fa000) at ../ports/sysdeps/unix/sysv/linux/arm/brk.c:28
#1 0xb6298826 in __GI___sbrk (increment=135168) at sbrk.c:53
#2 0xb626209a in __GI___default_morecore (increment=<optimized out>)
    at morecore.c:47
#3 0xb625f1e2 in sysmalloc (av=0xb62f54e8 <main_arena>, nb=72)
    at malloc.c:2462
#4 _int_malloc (av=av@entry=0xb62f54e8 <main_arena>, bytes=bytes@entry=64)
    at malloc.c:3800
#5 0xb6260576 in __GI___libc_malloc (bytes=64) at malloc.c:2891
#6 0xb636d0f4 in operator new(unsigned int) ()
   from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#7 0xa92c2b42 in core::dbus::Message::Reader::Reader(std::shared_ptr<core::dbus::Message> const&) () from /usr/lib/arm-linux-gnueabihf/libdbus-cpp.so.4
#8 0xa92c2cc0 in core::dbus::Message::Reader::pop_variant() ()
   from /usr/lib/arm-linux-gnueabihf/libdbus-cpp.so.4
#9 0xa9356a98 in core::dbus::Codec<core::dbus::types::Variant>::decode_argument(core::dbus::Message::Reader&, core::dbus::types::Variant&) ()
   from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1
#10 0xa9374608 in core::dbus::Result<core::dbus::types::TypedVariant<unsigned long long> >::from_message(std::shared_ptr<core::dbus::Message> const&) ()
   from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1
#11 0xa937484c in core::dbus::Result<core::dbus::types::TypedVariant<unsigned long long> > core::dbus::Object::invoke_method_synchronously<core::dbus::interface---Type <return> to continue, or q <return> to quit---
s::Properties::Get, core::dbus::types::TypedVariant<unsigned long long>, std::string, std::string>(std::string const&, std::string const&) ()
   from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1
#12 0xa9374a98 in core::dbus::Property<mpris::Player::Properties::Position>::get() const () from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1
#13 0xa93c6f66 in AalMediaPlayerService::position() const ()
   from /usr/lib/arm-linux-gnueabihf/qt5/plugins/mediaservice/libaalmediaplayer.so
#14 0xaaae6332 in QMediaPlayer::qt_metacall(QMetaObject::Call, int, void**) ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Multimedia.so.5
#15 0xb65ac518 in QMetaProperty::read(QObject const*) const ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#16 0xaaaba3e2 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Multimedia.so.5
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

and also:

(gdb) where
#0 __brk (addr=0x31d9000) at ../ports/sysdeps/unix/sysv/linux/arm/brk.c:28
#1 0xb6298826 in __GI___sbrk (increment=135168) at sbrk.c:53
#2 0xb626209a in __GI___default_morecore (increment=<optimized out>)
    at morecore.c:47
#3 0xb625f1e2 in sysmalloc (av=0xb62f54e8 <main_arena>, nb=128)
    at malloc.c:2462
#4 _int_malloc (av=av@entry=0xb62f54e8 <main_arena>, bytes=bytes@entry=120)
    at malloc.c:3800
#5 0xb6260576 in __GI___libc_malloc (bytes=120) at malloc.c:2891
#6 0xb636d0f4 in operator new(unsigned int) ()
   from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#7 0xb3f13224 in mir::scene::BasicSurface::compositor_snapshot(void const*) const () from /usr/lib/arm-linux-gnueabihf/libmirserver.so.24
#8 0xad14caba in qtmir::MirSurfaceItem::dropPendingBuffers() ()
   from /usr/lib/arm-linux-gnueabihf/qt5/qml/Unity/Application/libunityapplicationplugin.so
#9 0xb65c4274 in QMetaObject::activate(QObject*, int, int, void**) ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#10 0xb65cca36 in QTimer::timerEvent(QTimerEvent*) ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#11 0xb65c4eca in QObject::event(QEvent*) ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#12 0xb65a4f92 in QCoreApplication::notify(QObject*, QEvent*) ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#13 0xb65a4d88 in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#14 0xb65de45a in QTimerInfoList::activateTimers() ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#15 0xb65de70c in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#16 0xb5dbbf50 in g_main_context_dispatch ()
   from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#17 0xb5dbc0fc in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0

[Albert Astals Cid (aacid)]

Wouldn't it be much easier running something like valgrind-massif to know where the problem is?

[Colin Ian King (colin-king)]

Dunno, but anyhow, it's leaky and it's worth investigating IMHO

[Colin Ian King (colin-king)]

Related bug: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1364404/comments/3

[Gerry Boland (gerboland)]

Confirmed on my device. Using perf I see quite a few memory allocations and frees happening while device is idle.

[Gerry Boland (gerboland)]

I ran unity8 through valgrind with massif, with the commands

stop unity8
export MIR_SERVER_NAME=session-0
export MIR_SOCKET=/run/mir_socket
export QT_QPA_PLATFORM=mirserver
valgrind --tool=massif --time-unit=ms --detailed-freq=1 /usr/bin/unity8

 attached is a visualization of the data. unity8 was not touched.

It appears there's 2 sources of memory leaks, both appear on the android side.

[Victor Tuson Palau (vtuson)]

this bug should be critical

[Colin Ian King (colin-king)]

So the issue is in libubuntu_application_api; so is it related to bug #1206146

[Gerry Boland (gerboland)]

So far, I've tracked the problem down to the sensors part of platform-api.

android/hybris/ubuntu_application_sensors_for_hybris.cpp - looper_callback function - there's a leak somewhere

[Alberto Aguirre (albaguirre)]

@colin-king, yeah it's related to https://bugs.launchpad.net/bugs/1206146. I'm duping this to that bug. If there's other leaks please unduplicate.

Gerry, thanks for that narrowing that down, indeed platform-api is leaking on every sensor event notification in SensorListener::on_new_reading in android/default/default_ubuntu_application_sensor.cpp