0

Could anyone shed some light on the following crash report? Is there a way to prevent such crashes?

Build fingerprint: 'samsung/kltexx/klte:5.0/LRX21T/G900FXXU1BNL9:user/release-keys'
Revision: '14'
ABI: 'arm'
pid: 13847, tid: 16899, name: MediaCodec_loop >>> net.mydomain.myapp <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'frameworks/av/media/libstagefright/MediaCodec.cpp:967 CHECK_EQ( mState,CONFIGURING) failed: 9 vs. 3'
r0 00000000 r1 00004203 r2 00000006 r3 00000000
r4 9b2ffdb8 r5 00000006 r6 00000000 r7 0000010c
r8 00000000 r9 b55fa024 sl 9b2ffc74 fp 9b2ffc80
ip 00004203 sp 9b2ff7e0 lr b6f2ffd5 pc b6f53978 cpsr 600d0010

backtrace:
#00 pc 00037978 /system/lib/libc.so (tgkill+12)
#01 pc 00013fd1 /system/lib/libc.so (pthread_kill+52)
#02 pc 00014bef /system/lib/libc.so (raise+10)
#03 pc 00011531 /system/lib/libc.so (__libc_android_abort+36)
#04 pc 0000fcbc /system/lib/libc.so (abort+4)
#05 pc 00007af1 /system/lib/libcutils.so (__android_log_assert+88)
#06 pc 00098c8b /system/lib/libstagefright.so (android::MediaCodec::onMessageReceived(android::sp<android::AMessage> const&)+486)
#07 pc 0000a5a3 /system/lib/libstagefright_foundation.so (android::ALooperRoster::deliverMessage(android::sp<android::AMessage> const&)+166)
#08 pc 00009f25 /system/lib/libstagefright_foundation.so (android::ALooper::loop()+220)
#09 pc 0000ef11 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+112)
#10 pc 000603bd /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+72)
#11 pc 0000ea81 /system/lib/libutils.so
#12 pc 000137bb /system/lib/libc.so (__pthread_start(void*)+30)
#13 pc 0001189b /system/lib/libc.so (__start_thread+6)
fadden
  • 51,356
  • 5
  • 116
  • 166
Hong
  • 17,643
  • 21
  • 81
  • 142
  • 1
    It's an assertion failure in the mediacodec implementation. It's often possible to work around them. The AOSP 'L' sources are here: https://android.googlesource.com/platform/frameworks/av/+/lollipop-release/media/libstagefright/MediaCodec.cpp . The line number doesn't match up with a CHECK_EQ, so it's possible you've got a Samsung-modified version of the code. Could be line 889, could be a new assert. – fadden Feb 13 '15 at 17:23
  • Thanks for the response. All MediaCodec related code is in catch-try blocks to catch the general exception (i.e. Exception). Why is this not sufficient to prevent the crash? – Hong Feb 13 '15 at 19:43
  • 1
    This isn't a Java-language exception, it's a (deliberate) crash in native code, which means you can't catch and handle it. Workarounds usually takes the form of rearranging the app code to ensure that the situation never arises. The trick is figuring out what sequence of events causes the problem. According to the abort message, it's expecting to be in `CONFIGURING` (3) but is actually in `STOPPING` (9), suggesting that something is attempting to configure a MediaCodec that is in the process of shutting down. – fadden Feb 13 '15 at 21:29
  • Thank you for the elucidation. Your above comment should be the answer that I would happily accept. – Hong Feb 13 '15 at 22:30
  • Since there is no way to check the state of MediaCodec, it would be difficult to prevent this. – Hong Feb 13 '15 at 23:47
  • 1
    It requires experimentation, guesswork, and peering through the code to figure out why it's unhappy. Sometimes you can figure it out based on what call you're in the middle of. When working on screenrecord (in native code) I discovered that, if I failed to release() the object, the object's destructor would throw an exception some time later on a different thread... so cause and effect are not always easy to correlate. The bottom line is that the platform code should not crash this way, so this is a bug that should be fixed by Google... but that doesn't help you right now. – fadden Feb 14 '15 at 01:27
  • Thank you for all the tips. I will definitely keep all your comments in mind when examining the MediaCodec related code. Fortunately, this seems to happen rarely right now. – Hong Feb 14 '15 at 01:31

0 Answers0