项目使用了三方的一个盒子，发现硬解码经常崩溃，但这个盒子使用的是很高端的芯片MT6797，理论上界面能力应该强出天际才对。而且往往一路编码，5路解码直接就gg了。于是要分析一番。
我是搞应用的，看到崩溃时候的崩溃信息只有以下几行。
12-10 16:50:23.095 2763 4218 E IOMX : binder transaction failed: -2147483646
12-10 16:50:23.096 2763 4217 E MediaCodec: Codec reported err 0x80000002, actionCode 0, while in state 6
12-10 16:50:23.104 2763 4161 W System.err: java.lang.IllegalStateException
12-10 16:50:23.104 2763 4161 W System.err: at android.media.MediaCodec.native_dequeueInputBuffer(Native Method)
12-10 16:50:23.104 2763 4161 W System.err: at android.media.MediaCodec.dequeueInputBuffer(MediaCodec.java:2332)
看log就只有这些几行native_dequeueInputBuffer的错误，根本没法解决啊~
于是之后跟盒子厂家要源码继续搞了。
通过查看代码流程，这句log是在MediaCodec中打印的，所以老套路，加log，加backtrace。
这里面就有一个不得不说的坑，tm MTK居然把一些log搞没，搞到我找了很久。他是怎么把log搞没的呢？
他居然在头文件乱引入一些头文件，把
#ifdef MTK_AOSP_ENHANCEMENT
#define LOG_TAG "ACodec"
#include
#undef ALOGV
#define ALOGV ALOGD
#define ATRACE_TAG ATRACE_TAG_VIDEO
#ifdef HAVE_AEE_FEATURE
#include "aee.h"
#endif
#else
//#define LOG_NDEBUG 0
#define LOG_TAG "ACodec"
#include
#endif
好了，把上面一大坨删掉之后，log就回来了，舒服了。
那就继续打log和trace需要错误来源，最后发现是崩在了fillBuffer,这可吓我一跳了，难道真的是解码器的问题，那都是不开源的，没得解的。
status_t err = mCodec->mOMX->fillBuffer(
mCodec->mNode, info->mBufferID, info->mFenceFd);
info->mFenceFd = -1;
if (err == OK) {
info->mStatus = BufferInfo::OWNED_BY_COMPONENT;
} else {
ALOGE("wenfengtou fillBuffer failfuck");
ALOGE("wenfengtou fillBuffer failfuck, signalError %#x, fillBuffer %s, info->mBufferID %u", makeNoSideEffectStatus(err), mCodec->mComponentName.c_str(), info->mBufferID);
mCodec->signalError(OMX_ErrorUndefined, makeNoSideEffectStatus(err));
}
没办法，硬着头皮继续看看fillBuffer怎么实现的。通过在fillBuffer打log，发现错误的时候根本就没有进入下面的处理函数。有感觉有一些希望了。结合前面的第一个log，binder transaction failed，可能是binder通信失败了。
status_t OMXNodeInstance::fillBuffer(OMX::buffer_id buffer, int fenceFd) {
Mutex::Autolock autoLock(mLock);
OMX_BUFFERHEADERTYPE *header = findBufferHeader(buffer);
header->nFilledLen = 0;
header->nOffset = 0;
header->nFlags = 0;
// meta now owns fenceFd
ALOGE("wenfengtou OMXNodeInstance::fillBuffer info->mBufferID %u", buffer);
status_t res = storeFenceInMeta_l(header, fenceFd, kPortIndexOutput);
if (res != OK) {
ALOGE("wenfengtou OMXNodeInstance::fillBuffer error 1");
CLOG_ERROR(fillBuffer::storeFenceInMeta, res, EMPTY_BUFFER(buffer, header, fenceFd));
return res;
}
ALOGE("wenfengtou OMXNodeInstance::fillBuffer 222");
{
Mutex::Autolock _l(mDebugLock);
mOutputBuffersWithCodec.add(header);
CLOG_BUMPED_BUFFER(fillBuffer, WITH_STATS(EMPTY_BUFFER(buffer, header, fenceFd)));
}
OMX_ERRORTYPE err = OMX_FillThisBuffer(mHandle, header);
ALOGE("wenfengtou OMXNodeInstance::fillBuffer 333");
if (err != OMX_ErrorNone) {
ALOGE("wenfengtou OMXNodeInstance::fillBuffer error 2");
CLOG_ERROR(fillBuffer, err, EMPTY_BUFFER(buffer, header, fenceFd));
Mutex::Autolock _l(mDebugLock);
mOutputBuffersWithCodec.remove(header);
}
ALOGE("wenfengtou OMXNodeInstance::fillBuffer 444");
return StatusFromOMXError(err);
}
再次确认后，发现binder的确没有通。为啥呢？
硬着头皮，继续复现抓log，发现OMXNodeInstance的进程居然不在了，进程是mediaserver！！！
所有有可能是mediaserver挂了，导致binder失败。再一份log里面看到下面
12-18 11:58:36.083 293 1052 E Parcel : dup() failed in Parcel::read, i is 0, fds[i] is -1, fd_count is 2, error: Too many open files
我去，难不成是句柄溢出了。感觉看看mediaserver占了多少句柄，不看不知道，妈的，打开一个摄像头就占了500多个句柄（对比已经就100多个句柄），而我们知道系统限制一个进程用1024个句柄。
问了下盒子厂家，这个是bug吗，句柄占这么多？？他们说mtk就是这么叼，就是要占这么多。那每到办法了，只能让厂家修改代码突破这个1024句柄限制了。通过修改mediaserver的main函数代码如下，可以跑了终于。
struct rlimit newrlim;
newrlim.rlim_cur = 4096;
newrlim.rlim_max = 4096;
if (setrlimit(RLIMIT_NOFILE, &newrlim) == -1)
{
ALOGE("wenfengtou setrlimit fail");
} else {
ALOGE("wenfengtou setrlimit success");
}