4

I have a large multi-threaded open source application which uses proprietary OpenGL libraries, Wayland Weston, and a proprietary graphics driver in the Linux kernel. The drivers are currently under development, so there is a strong possibility that they have errors.

I have observed the following symptoms:

  1. Free memory (free -m) is continuously consumed while running my application. At a steady state, it consumes about 1MB/5minutes.

  2. If I stop and start my application continuously, I am able to accelerate the rate of memory loss. It looks like I lose about 0.5MB every time I restart the application.

  3. When I stop my application, the memory is not returned to the system. The memory is returned only after a power cycle.

  4. I have started to log memory usage, as well as taking snapshots of /proc/<pid>/smaps. I can see which thread consumes the memory, and I will investigate further.

  5. inspection of the smaps file shows that, over time, the older snapshot has consumed more memory. There are also more anon_inode:dmabuf entries in the older snapshot, and this looks similar to these issues:

    https://stackoverflow.com/questions/28097766/where-does-the-dev-zero-deleted-anon-inodedmabuf-comes-from-in-proc-p

    https://bugs.freedesktop.org/show_bug.cgi?id=100298

Is this memory leak more likely to be a user space memory leak or a kernel memory leak?

What other diagnostics can I perform to narrow down the likely source of leaks?

1

Is the application doing any anonymous memory allocations thru mmap()?
Any data or log files being written to a RAM disk? Got threads that are constantly starting and finishing? Handling thread terminations correctly? (Been there, found that as a leak.) If you wait a bit, does kernel memory usage drop off as dynamic structures get released?

I would put the odds of who is leaking memory at better than 99% in favor of the application.

  • I trust the application more than the libraries and kernel driver. It's a very large application, in use on many mass produced products. At this point, I'd like to narrow it down to either user space, or kernel space> BTW, I did find that another application was crashing, and creating core dumps in /tmp, so that explains some of the other memory loss. – Mr Stinky Oct 14 '18 at 7:46
  • I am seeing anon allocations in the smaps files, and the anon allocations are the ones which are growing over time. When I do the accelerated test, I can't use the smaps logging because the PID changes each time. Kernel memory usage does drop off over time in the single-run test. It does stabilise. – Mr Stinky Oct 14 '18 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.