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 Answer 1

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.

2
  • 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, 2018 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, 2018 at 7:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .