Open lancewoo opened 2 years ago
This seems to be a system level bug in Looper. This crash happened when a WorkerHandler thread was created and cached and a new CameraView instance was created and it was awaken up by an alarm. I finally changed how CameraEngine use the WorkerHandler to do a workaround. Whenever recreateHandler() is called, a new key is used to create a new WorkerHandler; when CameraEngine quits, the WorkerHandler quits then.
Thanks for the information. I don't fully understand what's going on though. Is there something the library could do, other than creating a new handler each time?
I strongly suspect there's something wrong with my version of Android Looper at the very core. https://android.googlesource.com/platform/system/core/+log/master/libutils/Looper.cpp
More information, the device we're using is for surveillance purpose on power towers. There's no user interaction. So we only set up alarms to do picture shots repeatedly, say, every 30 minutes. After each picture taken, the device would go into sleep mode to save battery as soon as possible. A crash may occur on each second wakeup to do a picture taking. If we delay some time, say, 100ms or more, to do the instantiation of CameraView, it seems the crash case would not be touched. Weird? Since this is probably a bug of the underlying Android system, as we can see from stacktraces of each crash, I don't think there is a need to do modifications to the CameraView. It is a great library. Thanks! Moreover, this crash case only occurred to an Android 9 device, not on other kinds.
Describe the bug
Please add a clear description of what the bug is, and fill the list below.
The scenario is like this. We had a timer set for taking pictures every 5 minutes. Occasionaly the app would get a SIGABRT to be killed when creating a new CameraView fragment for taking a new picture. After checking the logcat and stacktrace, we suspect that there might be something wrong with the states of CameraOrchestrator or WorkerHandler. So we passed true to recreateHandler in the CameraEngine constructor and never got crashed again. p.s. After 2 more days' of pressure tests, it crashed again.
https://github.com/natario1/CameraView/blob/00579814084fdc793fcf7246a00e5b05286ccd1f/cameraview/src/main/java/com/otaliastudios/cameraview/engine/CameraEngine.java#L158
My question is, is it possible that WorkerHandler used an old thread while its Looper had quit?
Expected behavior
A clear and concise description of what you expected to happen.
XML layout
Part of the XML layout with the CameraView declaration, so we can read its attributes.
Logs
Use
CameraLogger.setLogLevel(LEVEL_INFO)
to see all logs into LogCat.12-23 11:09:34.589 4590 4590 I #ST2303_CameraServer#: [(Camera2Fragment.java:256)#onCreateView] Camera2Fragment onCreateView(id=1) 12-23 11:09:34.602 4590 4590 W CameraView: doInstantiateEngine: instantiating. engine: CAMERA2 12-23 11:09:34.602 4590 4590 W WorkerHandler: get: Reusing cached worker handler. CameraViewEngine 12-23 11:09:34.603 4590 4590 W CameraView: doInstantiateEngine: instantiated. engine: Camera1Engine 12-23 11:09:34.603 4590 4590 I CameraOrchestrator: FACING - Scheduling. 12-23 11:09:34.604 4590 4590 F Looper : Could not write wake signal to fd 56: Bad file descriptor
pid: 4298, tid: 4298, name: er.cameraserver >>> com.senter.cameraserver <<< signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- Abort message: 'Could not write wake signal to fd 56: Bad file descriptor' r0 00000000 r1 000010ca r2 00000006 r3 00000008 r4 000010ca r5 000010ca r6 ffb304ac r7 0000010c r8 00000000 r9 efe48000 r10 12dc0f38 r11 00000000 ip f23a33cc sp ffb30498 lr f230ef95 pc f2305e5e
backtrace:
00 pc 0001ce5e /system/lib/libc.so (abort+58)