The bug turned out to be completely different from where it was expected

What was the initial concern?

In our application, we must have ONVIF cameras supported, and we decided to use the ExoPlayer to not write a ton of code for the RTSP layer. But there was a problem: when several video streams were opened concurrently, the application eventually failed. From the user's perspective, it seems like a crash, but looking at the logs, I've seen nothing. Really nothing was in there. Then, after going deeper, it appeared that our app caught an ANR error, and then the whole OS crashed because it ran out of available memory. The Java and native application memory did not fully explain the increase. And it was the first time I learned about DMA-BUF memory, and using the tools, I found out that DMA BUF actually increased significantly while the streams were active and did not return to the original level after the player instances were released.

Investigation path

The investigation was performed using the following sequence. First, DMA-BUF usage was collected while the system was idle, before starting the video streams. Next, six concurrent 1080p AVC streams were started using ExoPlayer and the default vendor hardware decoder, c2.rk.avc.decoder. While the streams were active, DMA-BUF usage increased from the normal baseline to several hundred megabytes (~300-400 MB). A per-process DMA-BUF dump was then collected to identify which processes held references to the allocated buffers. The dump showed that the android.hardware.media.c2@1.1-service process held approximately 579,360 kB of DMA-BUF memory while the six streams were running. All ExoPlayer instances were then released. After that, the application process was force-stopped to guarantee that all file descriptors and Binder references belonging to the application were closed by the operating system. A second per-process DMA-BUF dump was collected after the force-stop. The application process was no longer present, but android.hardware.media.c2@1.1-service still held exactly 579,360 kB of DMA-BUF memory. The file descriptors of the Codec2 service process were also inspected. While the streams were active, the process contained hundreds of /dmabuf: descriptors, multiple gralloc_shared_memory descriptors, and an open /dev/mpp_service descriptor. Finally, the android.hardware.media.c2@1.1-service process was terminated. After the service process was terminated, DMA-BUF usage dropped substantially toward the original system baseline. The service was subsequently restarted by Android with a new process instance and significantly fewer DMA-BUF descriptors.

So what's the lesson?

Sometimes, things may look like a standard workflow you dealt with all the years before. But apparently, sometimes you need to look at the situation from a completely different angle, and it may turn out that you are not at all to blame.