The previous blog introduced some functions and simple implementation of Android EasyRTMP App. This blog introduces a bug we encountered, its causes and solutions.
This bug occurs when the resolution is switched, and the app crashes occasionally. After continuous testing, we found that it is more likely to occur when switching from low resolution to high resolution. Later, when we checked the log, we found that the printed log was strange, and it was some Native layer. The crash, and no stack information is displayed:
--------- beginning of crash
09-21 13:39:26.636 24221 24231 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xc in tid 24231 (HeapTaskDaemon)
09-21 13:39:26.744 578 578 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-21 13:39:26.744 578 578 F DEBUG : Build fingerprint: 'Hisense/E76mini/HS8937QC:6.0.1/MMB29M/L1304.6.01.01:user/release-keys'
09-21 13:39:26.744 578 578 F DEBUG : Revision: '0'
09-21 13:39:26.744 578 578 F DEBUG : ABI: 'arm64'
09-21 13:39:26.745 578 578 F DEBUG : pid: 24221, tid: 24231, name: HeapTaskDaemon >>> org.easydarwin.easyrtmp <<<
09-21 13:39:26.745 578 578 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc
09-21 13:39:26.770 578 578 F DEBUG : x0 0000000000000004 x1 0000000000000000 x2 0000007f7b36bca0 x3 00000055a5c9bae0
09-21 13:39:26.770 578 578 F DEBUG : x4 0000000000000000 x5 00000000051fa000 x6 0000007f7f5e27c8 x7 4104100004104100
09-21 13:39:26.770 578 578 F DEBUG : x8 00000000002450a0 x9 0000000000001228 x10 00000055a5c9bb04 x11 0000000000000000
09-21 13:39:26.770 578 578 F DEBUG : x12 00000000000000ab x13 0000000000002ddd x14 00000055a5c9bb00 x15 00000000000000a9
09-21 13:39:26.770 578 578 F DEBUG : x16 00000055a5c9bb04 x17 0000000000000000 x18 0000000000002ddd x19 0000000000002de1
09-21 13:39:26.770 578 578 F DEBUG : x20 00000000706df038 x21 000000000000000c x22 0000007f7c2bb000 x23 0000007f7c2bf2f0
09-21 13:39:26.770 578 578 F DEBUG : x24 0000000000000000 x25 0000000079aeb000 x26 0000000000000003 x27 00000055a5c9c310
09-21 13:39:26.770 578 578 F DEBUG : x28 0000007f7b36bca0 x29 0000007f7b36bbe0 x30 0000007f7b36bca8
09-21 13:39:26.771 578 578 F DEBUG : sp 0000007f7b36bbe0 pc 0000007f7beb8e64 pstate 0000000080000000
09-21 13:39:26.787 578 578 F DEBUG :
09-21 13:39:26.787 578 578 F DEBUG : backtrace:
09-21 13:39:26.788 578 578 F DEBUG : #00 pc 000000000021fe64 /system/lib64/libart.so (_ZN3art2gc9collector9MarkSweep16ProcessMarkStackEb+220)
09-21 13:39:26.788 578 578 F DEBUG : #01 pc 0000000000220800 /system/lib64/libart.so (_ZN3art2gc9collector9MarkSweep12MarkingPhaseEv+256)
09-21 13:39:26.788 578 578 F DEBUG : #02 pc 0000000000220b58 /system/lib64/libart.so (_ZN3art2gc9collector9MarkSweep9RunPhasesEv+732)
09-21 13:39:26.788 578 578 F DEBUG : #03 pc 0000000000212cc8 /system/lib64/libart.so (_ZN3art2gc9collector16GarbageCollector3RunENS0_7GcCauseEb+296)
09-21 13:39:26.788 578 578 F DEBUG : #04 pc 000000000024506c /system/lib64/libart.so (_ZN3art2gc4Heap22CollectGarbageInternalENS0_9collector6GcTypeENS0_7GcCauseEb+2056)
09-21 13:39:26.788 578 578 F DEBUG : #05 pc 000000000024690c /system/lib64/libart.so (_ZN3art2gc4Heap16ConcurrentGCTask3RunEPNS_6ThreadE+152)
09-21 13:39:26.788 578 578 F DEBUG : #06 pc 000000000026963c /system/lib64/libart.so (_ZN3art2gc13TaskProcessor11RunAllTasksEPNS_6ThreadE+80)
09-21 13:39:26.788 578 578 F DEBUG : #07 pc 0000000001ffa57c /system/framework/arm64/boot.oat (offset 0x1ffa000)
09-21 13:39:27.169 578 578 F DEBUG :
09-21 13:39:27.169 578 578 F DEBUG : Tombstone written to: /data/tombstones/tombstone_03This kind of problem is generally caused by out of bounds or invalid memory. Think carefully about whether it is an internal bug of the encoder, for example, the 1080P resolution after switching is not supported?
Then we can shield the switching process first and try it directly with 1080P as the initial resolution?
OK, after changing the initial resolution to 1920*1080, it is found that it does not crash, it is not because the encoder does not support it.
Then think about it again, is it because of the old resolution parameters that are still used in the encoder initialization? This is also a very likely bug, because of this asynchronous switching, there are many first-come-first-served problems, so it is difficult It is comprehensive, and it cannot be executed in the order we expect, that is, the encoder is likely to be initialized with the old parameters, but the data frame is fed to the encoder with 1080P video frames.
I checked the code again and found that this is indeed the problem.
When switching the resolution, the width and height are performed in the main thread. After the resolution is changed, the resolution of the old camera is still used when the encoder is initialized. When the encoder is subsequently fed video data, the resolution of the video frame It has already been changed. At this time, the internal memory of the encoder will overflow.
The change method is to synchronize the switching process, that is:
According to this idea, all the actions in the chart need to be POSTed to the camera thread. After this modification, this bug will no longer appear.
About EasyRTMP Streaming SDK
EasyRTMP is a set of RTMP functional components with simple calls, complete functions, efficient and stable operation. After years of actual combat and online operation, it supports RTMP push disconnection and reconnection, ring buffering, intelligent frame loss, network event callback, and supports Windows and Linux. , arm (hisiv100/hisiv200/hisiv300/hisiv400/etc..), Android, iOS platform, supports most of the RTMP streaming media servers on the market, including Red5, Ngnix_rtmp, crtmpserver and other mainstream RTMP servers, can be perfectly applied to various Live broadcast needs of the industry, mobile live broadcast, desktop live broadcast, camera live broadcast, classroom live broadcast, etc.!
Click the link to join the group [EasyRTMP-RTMP live push]: 587254841
Get more information
Email: [email protected]
Copyright © EasyDarwin.org 2012-2017
