记一次GL error: Out of memory!的崩溃

现象描述：

设备外接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多次的时候崩溃而内存其实并没有异常。