【团队分享】苍翼之刃:论File Descriptor泄漏如何导致Crash?

这一期的团队分享,我们特邀苍翼之刃的开发负责人Jay,为大家分享在Android项目中遇到的一些Crash。

苍翼之刃 外文:BlazBlue Revolution Reburning,是由Arc Systerm Works 正式授权,并由 91Act 负责研发的横板动作手游,森利道全程监修,也是苍翼默示录系列唯一的一部横板动作手游。 游戏内部代号为:BBRR,全称是BLAZBLUE Revlution Reburning,续BBCT、BBCS、BBCS2、BBEX、BBCP 之后的又一力作。

背景

在*nix系统中,许多的资源都会被定义为File Descriptor(下面简称FD),例如普通文件、socket、std in/out/error等等。每个*nix系统中,单个进程可以使用的FD数量是有上限的。不同的*nix系统中,这个上限各有区别,例如在Android里面这个上限被限制为1024。

案例分析

在实际的Android开发过程中,我们遇到了一些奇奇怪怪的Crash,通过sigaction再配合libcorkscrew以及一些第三方的Crash Reporter都捕获不到发生Crash的具体信息,十分头疼。 然后我们通过Bugly上报的Java的CallStack观察发现这些Crash发现了一些共同的信息:

看来是和OpenGL有关系,于是我们进一步对程序输出的log进行观察,又发现:

从这个log里面我们获得了几个信息:

  1. 几乎所有出现这种Crash的设备,都是Adreno的GPU
  2. 几乎所有Crash都会伴随着requestBuffer failed

我们对我们已有的设备反复试验,确实了只有Adreno的设备(小米3,HTC M8,华为P7等)会在特定条件下出现这种奇奇怪怪的随机Crash。而其他设备例如小米Pad(Tegra),三星S3(Mali)等都不会出现这种问题。

这个问题确实头疼,在网上搜索了很久也没找到有用的信息。直到在某次小米3上再次测试的时候,发现了log里面还有一条必然出现的信息:

E/MemoryHeapBase(18703): error creating ashmem region: Too many open files

这个信息间接的指出了问题,也给了我们一些提示:似乎打开了过多的文件。于是靠着这个灵光,我们尝试着在程序中输出所有已打开的文件:

 SHOW FILE HANDLES:
 0  (socket:[285038]): read-write
 1  (/dev/null): read-write
 2  (/dev/null): read-write
 3  (/dev/log/main): cloexec write-only
 4  (/dev/log/radio): cloexec write-only
 5  (/dev/log/events): cloexec write-only
 6  (/dev/log/system): cloexec write-only
 7  (/sys/kernel/debug/tracing/trace_marker): write-only
 8  (/dev/__properties__):
 9  (/dev/binder): cloexec read-write
10  (/dev/log/main): cloexec write-only
11  (/dev/log/radio): cloexec write-only
12  (/dev/log/events): cloexec write-only
13  (/dev/log/system): cloexec write-only
14  (/system/framework/framework-res.apk):
15  (/system/framework/core-libart.jar):
16  (pipe:[282578]): nonblock
17  (/dev/alarm):
18  (/dev/cpuctl/tasks): cloexec write-only
19  (/dev/cpuctl/bg_non_interactive/tasks): cloexec write-only
20  (socket:[282569]): read-write
21  (pipe:[282570]):
22  (pipe:[282570]): write-only
23  (pipe:[282578]): nonblock write-only
24  (anon_inode:[eventpoll]): read-write
25  (/data/app/---app_name---/base.apk):
26  (/data/data/---app_name---/databases/bugly_db): cloexec read-write
27  (socket:[285047]): read-write
28  (anon_inode:mali-8938): cloexec
29  (socket:[282605]): nonblock read-write
30  (socket:[283605]): nonblock read-write
31  (/dev/null): read-write
32  (/dev/ump): read-write
33  (socket:[285045]): nonblock read-write
34  (/dev/null): read-write
35  (/dev/mali): read-write
36  (anon_inode:mali-8938): cloexec
37  (anon_inode:mali-8938): cloexec
38  (/data/app/---app_name---/base.apk):
39  (anon_inode:mali-8938): cloexec
40  (anon_inode:mali-8938): cloexec
41  (/dev/null): read-write
42  (/dev/null): read-write
43  (/data/app/---app_name---/base.apk):
44  (/dev/null): read-write
45  (anon_inode:mali-8938): cloexec
46  (/data/data/---app_name---/files/DefaultFont.ttf):
47  (/data/app/---app_name---/base.apk):
48  (anon_inode:sync_fence):
49  (/dev/null): read-write
50  (socket:[285060]): cloexec read-write
52  (anon_inode:mali-8938): cloexec
53  (anon_inode:mali-8938): cloexec
54  (/dev/null): read-write
55  (anon_inode:sync_fence):
56  (pipe:[284134]): write-only
58  (anon_inode:sync_fence):
62  (anon_inode:sync_fence):
63  (anon_inode:sync_fence):

通过不停测试程序,发现已打开的文件数量一直有增无减,而当这些被打开的文件数量接近1024的时候,上面的eglSwapBuffers必然出错。于是乎我们得出一个中间结论:

  • 如果程序打开的文件数量过多,会导致OpenGL swap buffer失败!

这从字面上看着似乎有些扯淡,因为这两者总感觉没啥联系。这个问题只会出现在Adreno的GPU上面,于是我们猜想:

  • Adreno的驱动在swap buffer的时候,需要申请新的FD,这个FD可能是某些硬件IO,具体不得而知;
  • 如果程序中其他的各种FD使用过多接近上限,会导致Adreno的驱动申请不到必要的FD,因此导致swap buffer失败。

这样看起来似乎就比较有道理了。虽然sawp buffer本身是不会Crash的,他并没有raise任何signal,只是简单的返回了一个错误的结果,但这会导致上层逻辑出现异常。这些异常在不同的设备上表现不一样:

  • 有的设备会在Java层的eglSwapBuffers触发Java层的Exception导致Crash;
  • 有的设备不会出现异常,但是会导致OpenGL停止工作(halt rendering),其表现结果就是程序卡住无响应;
  • 有的设备可能什么都不会发生,但是如果你的交互触发了其他逻辑:比如按回退键弹出对话框,对话框也需要FD,但是获得不到,那么弹出对话框的逻辑将抛出异常,

于是这就有了各种奇奇怪怪的Crash。

解决方案

通过对代码的排查,我们发现在使用SoundPool处理音效的时候,确实存在FD泄露的情况:

1  private SoundPool m_soundPool;
2  public int loadSound(String path) {
3      int soundID = m_soundPool.load(getAssets().openFd(path), 0);
4      return soundID;
5  }
6  public unloadSound(int soundID) {
7      m_soundPool.unload(soundID);
8  }

虽然我们在不需要这些音效的时候,对其进行了卸载处理,但不知道是SoundPool类自身的缺陷,还是我们的使用不当,在实际测试中我们发现unload过后,在load中通过openFd打开的FD并没有被释放掉。

强制调用System.gc()在一些设备(例如小米3)上可以释放掉这部分FD,但是另一些设备(例如HTC M8)即使强制gc这无法卸载掉它们,于是便出现了FD泄露的情况。

最终我们自行对这些FD进行管理,并且在unload的时候手动调用这些FD的close方法:

 1  private SoundPool m_soundPool;
 2  private HashMap<Integer, AssetFileDescriptor> m_soundFdMap
 3  public int loadSound(String path) {
 4      AssetFileDescriptor fd = getAssets().openFd(path);
 5      int soundID = m_soundPool.load(fd, 0);
 6      m_soundFdMap.put(soundID, fd);
 7      return soundID;
 8  }
 9  public unloadSound(int soundID) {
10     m_soundPool.unload(soundID);
11     m_soundFdMap.get(soundID).close();
12  }

这之后FD再无泄露的情况发生,之前的各种设备上面的各种奇奇怪怪的Crash都被处理好了。

小结

这个问题粗略说起来就是:因为播放了太多的音效,导致Adreno底层渲染失败,以至于上层逻辑各种失措,产生了很多奇奇怪怪的Crash。

准确的解释应该是:程序中的FD泄露如同内存泄露一样是同样需要得到关注的问题,FD的耗尽如同内存的耗尽一样会导致程序的各种异常情况发生,但是前者不如后者那么知名也不如后者容易被察觉。

小编有话说

不总结哪来经验,不分享经验何用?

在此小编号召大家多总结,互分享,踊跃给我们投稿,把自己踩过并爬出来的坑树个指示牌警醒后人,让猿们的开发生活更加美好!

投稿方式:将文章和个人介绍邮件到 bugly@tencent.com,字数不限。

本文系腾讯Bugly特邀文章,转载请注明作者和出处“腾讯Bugly(http://bugly.qq.com)”

腾讯Bugly,最专业的质量跟踪平台

原文发布于微信公众号 - 腾讯Bugly(weixinBugly)

原文发表时间:2015-05-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏码神联盟

高效编程所需要做的那点事

聊聊如果才能高效编程 计划(Plan) 所谓Plan,其实就是对应于编程中的设计阶段,当然,这里的Plan并不像设计那样重量级。它要求我们程序员在正式...

28690
来自专栏七夜安全博客

python基础教程第一课

17050
来自专栏Java架构

Java高级工程师——面试总结

22150
来自专栏微信公众号:Java团长

Java高级工程师面试总结

原因:面试的第一个问题,一般都是让你简单介绍下你自己,或者介绍一下你最近的项目,而一个面试者,如果连自己的简历都无法熟知,对里面提到的项目、技术都无法描述清楚的...

11010
来自专栏Java架构

金三银四如何找工作?阿里、京东、美团内推题送给还在迷茫的朋友从事Java开发工作十二年总结面试宝典一、阿里巴巴面试二、京东金融面试三、美团面试四、滴滴面试

38740
来自专栏腾讯Bugly的专栏

关于 Android N 那些你不知道的事儿

今年3月,Google 破天荒提前半年发布了 Android N 开发者预览版。当然,作为一个不合格的谷粉并没有第一时间体验安装,因为至今仍然能够回忆起来去年今...

35760
来自专栏程序人生

上帝说:要有一门面向未来的语言,于是有了 erlang

今个谈谈 erlang。 这些文章流于表面,更多是简单的介绍。这篇文章不同,因为 erlang 并不是一门新语言,简单介绍它的人不算少,我希望这篇文章能在深度上...

416110
来自专栏窗户

高速网络包过滤

  WAF(Web Application Firewall, Web防火墙)的实现有多种手段,基于regex(Regular Expression,正则表达式...

20170
来自专栏搜云库

防守式编程的艺术

原文地址:The Art of Defensive Programming 防守式编程的艺术 为什么开发人员不编写安全代码? 我们不再在这里讨论 “干净的代码”...

20490
来自专栏腾讯Bugly的专栏

iOS 9.1 深坑体验及其破解之道

众所周知,苹果iOS 9的推新速度已经打破了纪录,9.1刚刚于上周推出后,昨天,9.2 beta1已经出来了。 那么,到底iOS9都有哪些坑?网上能够搜索到的那...

28750

扫码关注云+社区

领取腾讯云代金券