Memory leak on Zoom preset

[mayanksuman]

Most of time, if someone enable Zoom preset, the application leak about 9 MB of memory.

To Reproduce

1. Open projecteur, Gnome system monitor and connect spotlight USB.
2. Make a couple of preset including Zoom preset in Spotlight tab.
3. Go to Device tab and inside input mapping: map double click to cycle preset.
4. Now, while enabling Zoom during preset cycling 9 MB of memory is leaked (on my system) most of time.

Desktop/Linux Environment (please complete the following information):

• Linux Distribution and Version: Debian 11

• Desktop/Window Manager and Version: Gnome 3.28

• Did you built Projecteur yourself?: [y/n] n

• What is the output of projecteur -f ?: ... Projecteur 0.9.1

  • git-branch: master
  • git-hash: 483d4a36e72de3c00f3d7f76207cc73e5a88a812
  • compiler: GNU 8.3.0
  • qt-version: (build: 5.11.3, runtime: 5.15.2)
  • device-scan: (errors: 0, devices: 1 [readable: 1, writable: 1])

• What is the output of projecteur -d ?: ... Projecteur 0.9.1; device scan

  • Found 1 supported devices. (1 readable, 1 writable)

  +++ name: 'Logitech USB Receiver' userName: 'Logitech Spotlight (USB)' vendorId: 046d productId: c53e phys: usb-0000:04:00.3-2 busType: USB devices: /dev/hidraw6, /dev/input/event22, /dev/input/event24, /dev/input/event23, /dev/input/event25 readable: true writable: true

[jahnf]

Hi Mayank, thanks for reporting, I will see if I can reproduce this. How did you measure this? (Just the system process view in Gnome does not tell you the whole truth.) I will do test runs with valgrind.

[mayanksuman]

I investigated this issue further and found this block in valgrind log:

==16066== 8,294,400 bytes in 1 blocks are still reachable in loss record 26,451 of 26,451
==16066==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==16066==    by 0x5C2E04D: QImageData::create(QSize const&, QImage::Format) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==16066==    by 0x5C2E26A: QImage::QImage(QSize const&, QImage::Format) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==16066==    by 0x5C2E2B2: QImage::QImage(int, int, QImage::Format) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==16066==    by 0x5C2EB62: QImage::copy(QRect const&) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==16066==    by 0xA2BFA5B: ??? (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15.2)
==16066==    by 0xA2AD6F8: QXcbScreen::grabWindow(unsigned long long, int, int, int, int) const (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15.2)
==16066==    by 0x5C0BB3E: QScreen::grabWindow(unsigned long long, int, int, int, int) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2)
==16066==    by 0x18078E: LinuxDesktop::grabScreen(QScreen*) const (linuxdesktop.cc:122)
==16066==    by 0x1A7330: ProjecteurApplication::ProjecteurApplication(int&, char**, ProjecteurApplication::Options const&)::{lambda(bool)#17}::operator()(bool) const (projecteurapp.cc:224)
==16066==    by 0x1AFC29: QtPrivate::FunctorCall<QtPrivate::IndexesList<0>, QtPrivate::List<bool>, void, ProjecteurApplication::ProjecteurApplication(int&, char**, ProjecteurApplication::Options const&)::{lambda(bool)#17}>::call({lambda(bool)#17}&, void**) (qobjectdefs_impl.h:146)
==16066==    by 0x1AF4C0: void QtPrivate::Functor<ProjecteurApplication::ProjecteurApplication(int&, char**, ProjecteurApplication::Options const&)::{lambda(bool)#17}, 1>::call<QtPrivate::List<bool>, void>({lambda(bool)#17}&, void*, {lambda(bool)#17}&*) (qobjectdefs_impl.h:256)
==16066== 

The desktopPixmap for window is never freed after allocating it on (projecteurapp.cc:224).

[jahnf]

After a brief look, I don't see why this should not be freed. The desktopPixmap property of the window is just an alias for the pixmap property of a ProjecteurImage instance belonging to the QmlEngine (instantiated from QML), also the QPixMap member is a regular member of ProjecteurImage and not a a pointer to a Pixmap. The ProjecteurImage instance should be cleaned up by the QmlEngine on exit.

But I still need to have a closer look within the next week.

[mayanksuman]

But I still need to have a closer look within the next week.

No need. I am going to close this issue.

I cannot reproduce this issue. By mistake, I got the valgrind log (pasted above) by pressing Ctrl+C on terminal.