qmlscene is leaking ~1.7K per second on an idle application on the phone

I can't seem to reproduce this on mako with just running calendar app and smemstat:ing it:

---
root@ubuntu-phablet:~# smemstat -p 3347 60
Change in memory (average per second):
  PID Swap USS PSS RSS User Command
  3347 0.0 B 1228.8 B 2133.3 B 1501.9 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene
Total: 0.0 B 1228.8 B 2133.3 B 1501.9 B

  PID Swap USS PSS RSS User Command
Total: 0.0 B 0.0 B 0.0 B 0.0 B

  PID Swap USS PSS RSS User Command
Total: 0.0 B 0.0 B 0.0 B 0.0 B
---

What I did I booted (mako rtm 22 image), launched calendar app and let it be idle. I also tried waking up the device, putting the app to background and waiting. The biggest I could get after the initial start of the app was:

  PID Swap USS PSS RSS User Command
  3347 0.0 B 68.3 B 85.3 B 136.5 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene
Total: 0.0 B 68.3 B 85.3 B 136.5 B

...when I switched it to background, after that 0 again. This was a 10 minute test.

If you can reliably reproduce the leaking, could you try using the instructions at https://wiki.ubuntu.com/Touch/QtTesting and try out Qt 5.3.1?

I searched through the 5.3.x point release git logs, and while there are a couple of leak fixes, there weren't any that would sound like happening when doing nothing. The most probable upstream source branches possibly containing fixes are the '5.3' ones (or '5.3.2' is currently as good) https://qt.gitorious.org/qt/qtbase/ and https://qt.gitorious.org/qt/qtdeclarative/, although note that the known leak we're hitting in bug #1201116 is in https://qt.gitorious.org/qt/qtxmlpatterns/ instead.

I re-flashed my mako today and tested it again and can reproduce the issue every time I test it. Perhaps you didn't have the display forced on (as described below).

How to reproduce:

1. Force the phone not to suspend:

powerd-cli display on bright &

2. Start calendar app and find the pid:

 ps -ef | grep calendar.qml

3. Trace:

smemstat -l -p 5236 60 5
Change in memory (average per second):
  PID Swap USS PSS RSS User Command
  5236 0.0 B 1228.8 B 1228.8 B 1228.8 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml
Total: 0.0 B 1228.8 B 1228.8 B 1228.8 B

  PID Swap USS PSS RSS User Command
  5236 0.0 B 1228.8 B 1228.8 B 1228.8 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml
Total: 0.0 B 1228.8 B 1228.8 B 1228.8 B

  PID Swap USS PSS RSS User Command
  5236 0.0 B 1160.5 B 1160.5 B 1160.5 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml
Total: 0.0 B 1160.5 B 1160.5 B 1160.5 B

  PID Swap USS PSS RSS User Command
  5236 0.0 B 1297.1 B 1297.1 B 1297.1 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml
Total: 0.0 B 1297.1 B 1297.1 B 1297.1 B

  PID Swap USS PSS RSS User Command
  5236 0.0 B 1228.8 B 1228.8 B 1228.8 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml
Total: 0.0 B 1228.8 B 1228.8 B 1228.8 B

And one can see that one of the threads is expanding the heap by 4K every ~3 seconds, which correlates with the heap expanding by a over 1K a second:

strace -f -t -p 5236 -e memory
[pid 5255] 13:11:37 mprotect(0xab0f6000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:11:40 mprotect(0xab0f7000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:11:44 mprotect(0xab0f8000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:11:47 mprotect(0xab0f9000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:11:50 mprotect(0xab0fa000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:11:54 mprotect(0xab0fb000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:11:57 mprotect(0xab0fc000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:12:00 mprotect(0xab0fd000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:12:04 mprotect(0xab0fe000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:12:07 mprotect(0xab0ff000, 4096, PROT_READ|PROT_WRITE) = 0
[pid 5255] 13:12:10 mmap2(0xab100000, 1048576, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xab100000
[pid 5255] 13:12:10 mprotect(0xab100000, 135168, PROT_READ|PROT_WRITE) = 0

I think the issue is that a thread is reading sensor data and leaking memory, I put a breakpoint on mprotect calls and found most are from:

(gdb) where
#0 mprotect () at ../sysdeps/unix/syscall-template.S:82
#1 0xb5eeb19c in grow_heap (diff=4096, h=0xb1400000) at arena.c:617
#2 sysmalloc (av=0xb1400010, nb=72) at malloc.c:2387
#3 _int_malloc (av=av@entry=0xb1400010, bytes=bytes@entry=64) at malloc.c:3800
#4 0xb5eec122 in __GI___libc_malloc (bytes=64) at malloc.c:2891
#5 0xb60420f4 in operator new(unsigned int) ()
   from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#6 0xb629e1a8 in QObject::QObject(QObject*) ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#7 0xb3a86eb4 in QSensorReading::QSensorReading(QObject*, QSensorReadingPrivate*) () from /usr/lib/arm-linux-gnueabihf/libQt5Sensors.so.5
#8 0xb3a890f8 in QAccelerometerReading::QAccelerometerReading(QObject*) ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Sensors.so.5
#9 0xb1fb123c in ?? ()
   from /usr/lib/arm-linux-gnueabihf/qt5/plugins/sensors/libqtubuntu_sensors_plugins.so
#10 0xb1f9f9fc in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I wonder if the sensor object pool is not freeing memory, there is an interesting comment:

void core::SharedAccelerometer::onAccelerometerReading(UASAccelerometerEvent *event)
{
    Q_ASSERT(event != NULL);

    // TODO(tvoss): We should rely on an object pool to recycle accelerometer reading
    // instances here. We could use a custom deleter for the shared pointer to put
    // instances that have been successfully delivered to slots back into the pool.
    QSharedPointer<QAccelerometerReading> reading(new QAccelerometerReading());

Based on those findings I'd move this to qtubuntu-sensors and give to tvoss.

I was able to reproduce the leakage now, indeed it was about keeping the screen on too.

I can also confirm the leaking stays the same when using Qt 5.3.1 (from https://wiki.ubuntu.com/Touch/QtTesting).