現象描述：
設備外接UVC攝像頭，使用uvccamera庫去打開，在進行打開->關閉壓測的過程中，發現到了940多次進程就崩潰，大致log如下：
2020-05-04 17:23:52.983 8657-8684/com.xx.xx E/Parcel: dup() failed in Parcel::read, i is 1, fds[i] is -1, fd_count is 2, error: Too many open files
2020-05-04 17:23:52.983 8657-8684/com.xx.xx E/Surface: dequeueBuffer: IGraphicBufferProducer::requestBuffer failed: -22
2020-05-04 17:23:52.984 8657-8684/com.xx.xx E/mali_so: encounter the first mali_error : 0x0002 : failed to allocate CPU memory (gles_fb_first_drawcall_cb at hardware/arm/mali_so_src_of_midgard/driver/product/gles/src/fb/mali_gles_fb_module_api.c:961)
2020-05-04 17:23:52.985 8657-8684/com.xx.xx E/OpenGLRenderer: GL error: Out of memory!
2020-05-04 17:23:52.985 8657-8684/com.xx.xx A/OpenGLRenderer: GL errors! frameworks/base/libs/hwui/renderthread/CanvasContext.cpp:550
--------- beginning of crash
2020-05-04 17:23:52.986 8657-8684/com.xx.xx A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 8684 (RenderThread)
2020-05-04 17:23:53.089 20578-20578/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2020-05-04 17:23:53.089 20578-20578/? A/DEBUG: Build fingerprint: 'xx/xx/xx:7.1.2/NHG47K/41:user/release-keys'
2020-05-04 17:23:53.089 20578-20578/? A/DEBUG: Revision: '0'
2020-05-04 17:23:53.089 20578-20578/? A/DEBUG: ABI: 'arm64'
2020-05-04 17:23:53.090 20578-20578/? A/DEBUG: pid: 8657, tid: 8684, name: RenderThread >>> com.xx.xx <<<
2020-05-04 17:23:53.090 20578-20578/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2020-05-04 17:23:53.101 20578-20578/? A/DEBUG: Abort message: 'GL errors! frameworks/base/libs/hwui/renderthread/CanvasContext.cpp:550'
2020-05-04 17:23:53.102 20578-20578/? A/DEBUG: x0 0000000000000000 x1 00000000000021ec x2 0000000000000006 x3 0000000000000008
2020-05-04 17:23:53.102 20578-20578/? A/DEBUG: x4 00006e6174736e69 x5 0000000000000000 x6 0000007c2158f000 x7 0000000000ad38f8
2020-05-04 17:23:53.102 20578-20578/? A/DEBUG: x8 0000000000000083 x9 ffffffffffffffdf x10 0000000000000000 x11 0000000000000001
2020-05-04 17:23:53.102 20578-20578/? A/DEBUG: x12 0000000000000018 x13 000000005eafdf28 x14 003aa793d8b06ae8 x15 00001b0e452dab8b
2020-05-04 17:23:53.102 20578-20578/? A/DEBUG: x16 0000007c1ed2aee0 x17 0000007c1ecd4b38 x18 0000000000000000 x19 0000007c142824f8
2020-05-04 17:23:53.102 20578-20578/? A/DEBUG: x20 0000000000000006 x21 0000007c14282450 x22 0000000000000018 x23 0000007c14281c90
2020-05-04 17:23:53.102 20578-20578/? A/DEBUG: x24 0000007c1f73a34c x25 0000007c1f73a040 x26 0000000000000001 x27 0000007bdcc11920
2020-05-04 17:23:53.102 20578-20578/? A/DEBUG: x28 0000007c115cd270 x29 0000007c14281710 x30 0000007c1ecd1f64
2020-05-04 17:23:53.102 20578-20578/? A/DEBUG: sp 0000007c142816f0 pc 0000007c1ecd4b40 pstate 0000000060000000
2020-05-04 17:23:53.121 20578-20578/? A/DEBUG: backtrace:
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #00 pc 000000000006bb40 /system/lib64/libc.so (tgkill+8)
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #01 pc 0000000000068f60 /system/lib64/libc.so (pthread_kill+64)
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #02 pc 0000000000023f58 /system/lib64/libc.so (raise+24)
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #03 pc 000000000001c810 /system/lib64/libc.so (abort+52)
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #04 pc 0000000000010d10 /system/lib64/libcutils.so (__android_log_assert+224)
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #05 pc 0000000000032b28 /system/lib64/libhwui.so
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #06 pc 0000000000035260 /system/lib64/libhwui.so
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #07 pc 000000000003ab30 /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv+152)
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #08 pc 00000000000124b4 /system/lib64/libutils.so (_ZN7android6Thread11_threadLoopEPv+272)
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #09 pc 000000000009f210 /system/lib64/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+116)
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #10 pc 0000000000068748 /system/lib64/libc.so (_ZL15__pthread_startPv+208)
2020-05-04 17:23:53.122 20578-20578/? A/DEBUG: #11 pc 000000000001da7c /system/lib64/libc.so (__start_thread+16)
2020-05-04 17:23:54.607 600-20582/? W/ActivityManager: Force finishing activity com.sensetime.demo/.ui.MainActivity
解決思路
粗略一看，感覺好像與renderthread有關，畢竟是直接現場；再一看，好像是內存泄漏了， 畢竟報了Out of memory；然後就去用free、dumpsys meminfo等監測內存的變化，發現就算到了崩潰之前，內存佔用也是正常的，奇怪了。
root cause
注意到最上面一行
2020-05-04 17:23:52.983 8657-8684/com.xx.xx E/Parcel: dup() failed in Parcel::read, i is 1, fds[i] is -1, fd_count is 2, error: Too many open files
報了fd的錯誤，Too many open files，於是可以去看看proc下面具體打開的fd是哪些
ls -la proc/pid/fd/
pid換成要監控的進程號，發現每次打開預覽都保留了usb下面的fd，關閉的時候卻沒有釋放，導致單進程持有fd超過1024的限制所以崩潰了，也能解釋爲什麼每次都是到940多次的時候崩潰而內存其實並沒有異常。