6

I our company we have a lot of ui-tests which are run on virtual/real devices. After running for some time tests randomly crashing, which I think is the result of file descriptor exceeding: I used

ls /proc/${PID}/fd | wc -l and lsof -p ${PID} but it did not help a lot - most of the rows in lsof looks like:

30015    u0_a104  678      sock                                    859560 socket:[859560]
30015    u0_a104  679      0000                0,8                 4539 anon_inode:[eventpoll]
30015    u0_a104  680      0000                0,8                 4539 anon_inode:[eventfd]
30015    u0_a104  681      0000                0,8                 4539 anon_inode:[eventfd]
30015    u0_a104  682      0000                0,8                 4539 anon_inode:[eventpoll]
30015    u0_a104  683      0000                0,8                 4539 anon_inode:[eventfd]
30015    u0_a104  684      0000                0,8                 4539 anon_inode:[eventpoll]
30015    u0_a104  685      0000                0,8                 4539 anon_inode:[eventfd]

So my question is: is there any android/java/linux instruments/utils to find the source of leakage?

P.S. System.gc() did not help

Art
  • 903
  • 9
  • 20

1 Answers1

8

I have researched for this question for a while and would like to share what I found:

  1. File descriptor are used in Android at least for:

    • Network sockets (or another type of file)
    • Mapped to memory files
    • Threads - so it was my case. See below why

  2. If you have created a HandlerThread, even if the last link to the HandlerThread instance will disappear thread will still work and consume FileDescriptor

  3. Threads in android can be seen:

    • In "Java heap dump" in Memory Abalyze Tool - so I have seen > 500 threads while running intsrumentation tests - they "eat" all file descriptors
    • Via terminal on android device adb shell ps -t or just ps -t
Art
  • 903
  • 9
  • 20