org.altbeacon.beacon.service.MonitoringStatus org.altbeacon.beacon.service.ScanState.getMonitoringStatus() #887
Comments
|
Thanks for this report. I stumbled across this today, too. I suspect this crash was introduced by a change in 2.15.2 that puts the call to The fix for this crash would be to treat mScanState as nullable and properly protect against a NPE on each access. |
|
The same problem on Nexus 5X with Android 8.1.0 and library version 2.16.2 |
|
Same issue here |
|
Attempted fix in #890 |
|
@mzTeamMeatMan, @jmvines and @pawelmarchewka, can you please try this beta release with the fix and let me know if you see the crash go away? https://github.com/AltBeacon/android-beacon-library/releases/tag/2.16.3-beta1 |
|
@davidgyoung , |
|
@davidgyoung I have tested 2.16.3-beta1 and haven't noticed any crash. Unfortunately, I noticed a different problem (maybe related to fixing that crash) - I cannot stop ranging beacons in region. After calling |
|
@pawelmarchewka, do you have specific steps to reproduce this? I can't figure out what might cause that exception just by looking at code. I really need to reproduce myself to figure out what causes it. (It might also be helpful if you can set |
|
@davidgyoung, I need to find the nearest beacon with specific UUID, so I scan for nearby beacons for few seconds:
A logcat file with |
|
@pawelmarchewka, I am not able to reproduce this with the reference app on a Pixel 3a with 9.0. Below is my test setup. Is anything significantly different than what you have? How are you scheduling the stop after 6 seconds? Which thread does that happen on? |
|
@davidgyoung, I prepared a small example application based on our code but:
|
|
@pawelmarchewka, looking at the sample code I notice that the scanning start/stop is handled on a thread managed by a coroutine Dispatchers.Default. Nothing wrong with that, but that different thread might somehow make the difference here. I wonder if the thread trying to stop scanning is somehow blocked. Unfortunately, I don't have any devices with Android 8.1 -- all are on Android 9 at this point. I believe I the I will do some testing with logging the thread id during the stop scanning process to see if that sheds any light on what is going on. |
|
@davidgyoung, I don't think that a thread trying to stop scanning is blocked:
I have tested my example app on two additional phones with Android 8.0 (LG G6 and Samsung Galaxy S7), and I can confirm the issue on both of them. Finally, I changed the dispatcher to Maybe all methods like |
|
Using the UI thread probably resolves the problem just because it subtly changes the timing of the way things happen. Investigating your logs further, I believe this problem is simply a race condition caused by anotherside effect of #878 Here's the sequence:
Here is that sequence: the last line with Before #878, this was not possible to happen because the main thread was blocked while the ScanJob was starting up. Now that this start up happens on a new thread, the race condition can happen. I believe a the solution to this is to simply check if the ScanJob was stopped before calling start() on CycledLeScanner. I also suspect the problem could be reproduced on any device by repeatedly calling startRangingBeaconsInRegion/stopRangingBeaconsInRegion many times in a loop. |
|
Wow. I just cannot reproduce this with the reference app, or with the app you shared, @pawelmarchewka. I have tried with the reference app and:
I still cannot reproduce on any of these devices even if I start and stop ranging 100 regions in a row: @pawelmarchewka, I also tried with your app running on the Nexus 5X Android 8.0 emulator with one modification to the init of ClipDetector.kt to enable a BeaconSimulator so ScanJobs will run on the emulator: I do not doubt you see this crash, but I just can't reproduce the problem to verify my proposed fix in #896. @pawelmarchewka, I can roll a build to have you test it again, unless you have a better idea. |
|
@davidgyoung, as I mentioned, I was able to reproduce this problem only on devices with Android 8.X (I tried on other versions of Android), and I never tested it on an emulator. If you can prepare another beta, it would be great - with my example app and three devices with Android 8.X I can test your fix quite easily 🙂 |
|
@pawelmarchewka , the release is here: https://github.com/AltBeacon/android-beacon-library/releases/tag/2.16.3-beta2 Yes, I realize you could only reproduce on Android 8.x, which is why I tried on the emulator. Strange that I could not reproduce there. Please try the release with your app that reproduces the problem and let me know what you see. |
|
@davidgyoung, thank you for preparing
|
|
@pawelmarchewka, it seems it is impossible to use logic to guarantee preventing the race condition that starts a scan after a job is stopped. So I resorted to using synchornized blocks in this release: https://github.com/AltBeacon/android-beacon-library/releases/tag/2.16.3-beta3 I did note when preparing this change that the stack trace shown is the result of a warning-level log from the library, not an actual crash. So while this adds log noise, and I'd like to eliminate it, I don't think is nearly as serious as the crash that caused this issue to be opened. That clarification aside, please do try the beta3 release if you have time and let me know if that makes it go away on the LG G6. |
|
@davidgyoung, the crash/warning was never my main concern, but if scanning has been stopped (or not) after calling I have tested |
|
Sorry, @pawelmarchewka the beta3 build that intended to add synchronization did nothing because I synchronized on the wrong object during ScanJob startup -- I used One clarification -- I do not think the scans are actually left on despite the warning say it cannot stop the scan. The scans are previously stopped successfully during job shutdown. The scan stop that causes the warning and stack trace are the regular cycled scanning of the library (which should be shut down cleanly but are clearly not due to this race condition). So when the warning appears, the CycledLeScanner is trying to do the regular periodic scan stop (despite the fact that the scan is alrady stopped) because it does not realize that it is supposed to be shut down. That said, the warning does create noise I'd like to eliminate. |
|
@davidgyoung, I have tested |
|
Great, thank you for sticking with this, @pawelmarchewka |
Hi @davidgyoung I am also facing the issues mentioned in this thread.
This happens randomly sometimes.
I am using implementation 'org.altbeacon:android-beacon-library:2+' in my dependencies. Can you please guide me as what is causing this issue and how can i resolve it. |
|
@davidgyoung we've had 2.16.1 since February in production and haven't had major issues with it. Recently we've pushed an update to the app which included various dependency and configuration updates (like ABI filter change required by Google Play) as well as upgrade to AltBeacon 2.16.2. Since then we've started getting series of strange crashes from both background and foreground on different devices: OnePlus5 Android 9: OnePlus5 Android 9: OnePlus5, Android 9: OnePlus5 Android 9, Galaxy S7 Android 8, HUAWEI Y5 2018 Android 8.1: Most of the listed crashes happened one after another on our test device, so we've considered it as a glitch or some sort of reaction on large amount of beacons in the office, but the last one happened in production on two devices which I'm pretty sure had no beacons in vicinity at the time of the crash. Since it happens pretty often (but still without steps to reproduce) on OnePlus5 which is in the office I can collect extra information if necessary. |
|
Please use the 2.16.3-beta4 release to solve the original crash on this thread, then provide feedback that that release solved it for you and did not cause new problems. Once I have sufficient confirmation I will roll a non-beta release. Please do not add new crashes to this issue. This is a closed issue. |
|
Hi @davidgyoung i integrated 2.16.3-beta4 release and is not getting the crash. Thanks for providing the solution. |
|
I am experiencing this issue as well for 2 devices over the weekend. Both android I've added the beta 4. Will report with my testing results. Including the stack traces, just in case. and |
|
@davidgyoung Haven't observed any crashes once our devices upgraded to the beta4. Tested on samsung/nexus 9, android versions |
|
Thank you all for the feedback. This is now in release 2.16.4 |
"androidversion":"8.0.0","brand":"HUAWEI HONOR DUK-AL20",
Android 2.16.2
E/JobServiceEngine: Application unable to handle onStopJob.
java.lang.NullPointerException: Attempt to invoke virtual method 'org.altbeacon.beacon.service.MonitoringStatus org.altbeacon.beacon.service.ScanState.getMonitoringStatus()' on a null object reference
at org.altbeacon.beacon.service.ScanJob.startPassiveScanIfNeeded(ScanJob.java:139)
at org.altbeacon.beacon.service.ScanJob.onStopJob(ScanJob.java:171)
at android.app.job.JobService$1.onStopJob(JobService.java:76)
at android.app.job.JobServiceEngine$JobHandler.handleMessage(JobServiceEngine.java:117)
at android.os.Handler.dispatchMessage(Handler.java:108)
at android.os.Looper.loop(Looper.java:166)
at android.app.ActivityThread.main(ActivityThread.java:7425)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:245)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:921)
The text was updated successfully, but these errors were encountered: