-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] QuickCapture - when device sleeps, app eventually crashes #196
Comments
@pjdohertygis Our guess is that the crash is caused by the map (by Runtime). Can you try the above workflow without opening the map page, see if it still crashes? In the meantime, we're doing some tests too to investigate this. |
Ok I will test this tomorrow with the map closed. Thank you! |
@xiao8579 so results below suggest perhaps it is the map causing the crash. I'll try one more test tomorrow with map open on the SONIM device. |
@pjdohertygis - Are you still seeing this issue? |
These QC crashes seem like they may be related to this issue. 20231211 QC crashed / quit Samsung Galaxy A53 during online tracklog entry. I did not have the map open. Start 12/11/2023 5:02 PM Pacific, crash ‘End Time 12/11/2023 5:02 PM’ Track Length 6.69 miles marked with Other waypoint at 10SEH2583656221. [Traced remainder of the route via IM 1.0 as ExB 2.0 was difficult.] |
@KeithJGw - What version of Android is running on the device? |
@JohnHasthorpe Sorry, I neglected to log the version at those times and know now to do so. For the A53, it's updated once or twice since the first occurance since returning from InSPIRE and one update since 12/11/2023. |
Note: I've been able to enter several hundred miles of tracklogs on a Samsung A53 Android v14 without QC crashing except for those two times. |
@JohnHasthorpe - I still see this issue almost every time I go hiking on v1.17 and now v1.18. Currently I am testing on v1.18.94, iPhone 13, ios 17.1.2. It may be related to going in and out of coverage but is very hard to replicate. Usually I am out hiking with tracklogs running, my iPhone will be locked and in my backpack outer pocket. When I get to the top of a peak to take photos and open QuickCapture, it will crash and open up again. The tracklog will be accurate up to the point of crash and local to the device. It sounds like this is happening in training and real-world events but going unreported. I even tried restarting my phone to make sure it is not a memory issue. I've sent along the diagnosis to quickcapture email, but not positive it will be capture in the logs. I'll keep testing. |
@pjdohertygis - Could you share some further information:
We have your logs and review |
@JohnHasthorpe Good questions. I will try to setup some testing sessions and reproduce the issue based on the questions below. As of 1/4 here is what I know / don't know. I'll also ask our user community to pay closer attention and report if they see this particular issue. During Hurricane Idalia, one task force (not a FEMA task force) complained that the app crashed several times, but the complaint didn't reach us for months later. Does the app crash at the point that you open the app? In at least some instances, yes, I go to open it by swiping up (iPhone) and finding the app. At that point it goes to the orange screen to reload the app. In other instances, I recall the app just being closed on its own already. Is location sharing on during the crash? i.e. is anything being sent to the server? Generally yes I share location using our Sandbox Location Sharing Project. I'll do more testing with both and see if there is a pattern. Has the project map been opened in the QuickCapture project? Generally at some point I will open the project map before starting the hike - unsure if it was "left open" when I locked my phone. I will test leaving the map open, locking my screen and then hiking. How long has the app been recording a line before you get to the peak (i.e. what is the travel time)? 2-3h maximum, in at least one instance only an hour. I'll start to keep track of that as well Is console UI and logging active in the app? If so, can you re-test with both switched off? No I've turned off the console UI since you last mentioned this is an issue and don't think that is a factor since it has been happening since before I knew that existed. |
This weekend 01/06 and 01/07 I did two tests with no crashes. Test 1 - 90 minute hike, using location sharing, and map was left open while phone is locked. Intermittent internet. but never lost it entirely. Next weekend I'll try to get a longer more remote hike in that is more similar to US&R conditions during a hurricane. |
@JohnHasthorpe after additional testing, it appears that we can replicate crashing behavior. Open project Next we will try to see if this a memory issue by comparing the crash rate with a freshly restarted phone or note. |
Thanks for this feedback Paul. We will see if we can mirror this behaviour. |
-------------Updated report using our new GitHub template-------
App
Device / OS
Describe the Bug - App will crash (either close entirely or reload the orange loading screen) when the phone is locked and device has tracklogs on. We are still trying to determine if it is related to location sharing and/or having the map open.
Expected Behavior - App should not crash when collecting tracklogs for extended periods of time and varying internet connectivity.
Reproduction Steps -
Project(s)
Sandbox https://arcg.is/14fK4
Sandbox with Location Sharing (requires NSARGC access, contact Paul or Jared)
Scenario 1 - Long duration, tracklogs turned on, location sharing turned on. Go for a hike or long drive where there is intermittent internet access. It seems to occur most often when I go on hikes to the top of a mountain and take photos outside of the app. This may be coincidental but start with this use use case and narrow down the cause once it is replicated.
Scenario 2 - Same as Scenario 1 but with the Sandbox Project (no location sharing).
Scenario 3 - TBD.
Priority Impact: p1 time sensitive
Impact
This crash may be occuring during incidents and not being reported. The outcome is potentially lost data if they did not know the app crashed and they continue searching an area. Therefore, while challenging to reproduce it is ideal if identify the root cause and fix ASAP.
------------Initial Report------------------
Here are results of a test I did yesterday. Is this expected? Is this something that is being addressed in v1.13 already or a new issue I should report through Esri Support?
I think the biggest concern isn't just the crash, it is the fact that there wasn't even an error message so the end user would not know it crashed.
[@xiao8579 @IsmaelInRedlands - hoping you are getting some well-deserved actual time off, but will send this is an email early next week, I just didn't want this to slip through the cracks.]
The text was updated successfully, but these errors were encountered: