Examining applications that do not terminate on std::bad_alloc

https://www.youtube.com/watch?v=QIiFsqsb9HM

如何处理std::bad_alloc以及OOM?作者对许多lib/app的处理方式进行了总结,分析和统计。

bad_alloc并不一定是OOM, 比如 std::vector<int>(-1) 在进行参数校验阶段也可能出现 bad_alloc. 不过这里主要还是分析OOM的情况。

C libs在处理malloc返回nullptr时有几种处理办法:return error code, longjmp, give up/fail fast. C++处理bad_alloc的方式其实也差不多,就是能catch住。但是其实前面两种办法也不能很好应对,可能是hang住,也可能在其他地方crash. 这个作者后面会对实际应用程序表现进行分析。


作者在Debina code search上针对 catch bad_alloc 做了统计分析

  1. 46% 交给上层进行处理
  2. 21% 进行清理和终止
  3. 9% 重试或者是更换策略
  4. 18% 取消或者是回滚
  5. 剩下6%出现在UT中

survive-on-bad-alloc0.png

survive-on-bad-alloc1.png

survive-on-bad-alloc2.png

survive-on-bad-alloc3.png

survive-on-bad-alloc4.png


大部分代码都对std_alloc进行了处理,但是实际效果如何呢?并不是特别理想。作者针对Offcie, IDE, Web Browser, Database做了分析. (作者也说了还是有不少DB其实是没有crash的)

survive-on-bad-alloc5.png

survive-on-bad-alloc6.png

survive-on-bad-alloc7.png

survive-on-bad-alloc8.png


最后作者给了几个应对bad_alloc的建议:

  1. 用户肯定是希望软件可以应对bad alloc的
  2. RAII是个好东西,但是不要在dtor里面抛出bad_alloc
  3. 不用追求完美,可以使用各种混合方案,只要能控制住就行
  4. 不要低估库对bad_alloc的影响,如果库本身就不是exception safe的就惨了。