[UnifiedMap] [nightly] crash on panning / zooming / loading caches on map #15726
Comments
murggel
added
Bug
murggel
changed the title
|
I sent the enhanced logfile to support-mail |
murggel
added
the
Prio - High
|
Reproducible on mapping large lists and with live map |
|
Hmmm ... also had a lot of UM crashes, but they only started yesterday (with 2024.05.12-NB), before (always with latest nightly) it was fine. Ok, admittedly not really perfect, every now and then a crash (mainly on immediate actions after starting UM, kinda reproducible if you do any actions before the map rendering is finished), but not as frequent as yesterday (nearly every 3 to 5 minutes). And it even happened while just driving on a route to a UDC, without any other action, the phone was just sitting in it's mounting bracket (see comment 2106899028). And at the same times when c:geo crashed, Bluetooth went away, too, which is why I thought it might be a device issue. But today I drove the exact same route again (only in opposite direction and finished a bit earlier), with UM disabled, and both c:geo and the phone behaved fine. However, will try again this evening, then with UM activated ... |
|
Ah, just seen: You reported the crashes with 2024.05.12-NB - but earlier UM crashes can also be found in Logcat ... |
Because I don't update every day and they just happened with that update for me |
|
Doesn't happen on Google-Maps |
|
On OSM it definitely does. And it seems to do something really bad, because it always takes some other apps with it. Tested again this afternoon, drove about 100 kilometers with classic map, with no problems at all. On my way back home I switched to unified map and it took not even minutes till the first crash: screen turned black, as usual, and after a few seconds cgeo came back, but not with the map but with the details page of the last cache viewed - and two of my background apps were gone. Tried this a second time, just shortly switched back to Android's home screen to restart my apps, but on return to cgeo via the last apps screen, it crashed again. After it's rebirth it then even ran for a couple of minutes, but then crashed again. Maybe understandable that after that I went back to classic map. Which is not only way faster but even as stable as I would expect it to be. ;) |
|
I will try to debug into it tonight... |
|
Last exception I found in the logfile is this one: This seems to be a somewhat older codebase, before commit 39b5ccc / PR #15677. |
|
With current master I can't redroduce it in emulator - I will install current nightly on my device and test it |
I downloaded the crashing version on 2024/05/12 at 7 am in the morning ... |
Still crashes with current nightly |
|
Is there a possibility to delete previous log entries, so only the entries of current session are logged / written in the log-file? |
Correct - those entries are with the version before ... |
|
Logfile from today There are some other messsages: 05-13 21:41:23.561 20536 20536 I ToolbarWidgetWrapper: Progress display unsupported |
|
I just imported the settings from my device to the emulator - still no crash in emulator to reproduce... |
Not that I know of any specific option to achieve this. Logcat behavior known to me always deletes all old messages after an export, thus you would get only new ones on next run. (At least that's the behavior I observe when creating logs from within c:geo= |
I can't find any new Java exceptions in here, only a couple of messages marked as "error". The error in GeoItemLayer.remove call seems to be logged only, but not leading to an actual crash (see GoogleV2GeoItemLayer.java line 144). Not sure where the "No package ID ff" error comes from. Other than that I don't see any reasons why it should crash. Strange 🤔 |
Unfortunately not in my case, the logs form 2024-04-29 are still written in the new log |
|
I don't have an idea, why it does not happen in the emulator .... I can try to install the debug-version on my device... and see what happen then |
|
Here the COMPLETE log-output of launching current master from AndroidStudio on my device, no exception at the end, but c:geo crashed 2024-05-13 22:37:43.232 682-682 audit auditd E type=1400 audit(1715632663.223:222363): avc: granted { execute } for pid=25294 comm="install_server-" path="/data/data/cgeo.geocaching.developer/code_cache/install_server-75d1b755" dev="sda32" ino=1509339 scontext=u:r:runas_app:s0:c106,c258,c512,c768 tcontext=u:object_r:app_data_file:s0:c106,c258,c512,c768 tclass=file SEPF_SM-G980F_12_0001 audit_filtered |
|
This was just starting c:geo and opening the map - no panning or zooming, but visible caches count > 200 Edit: to get an approx. cache count, II zommed so there were ~70, ~90, ~110, ~180, ~220 caches count - crash with the last one |
|
@moving-bits anything I should try / can configure to get more information? |
|
Already using |
|
Nothing new over here? Unified Map is still completely unusable with OSM offline, lags like hell and crashes c:geo on the smallest moves in the map. And this not only with a time-honored Huawei P30Pro (which BTW is still top) with Android 10, but with a completely new Honor Magic6 Pro and Android 14 as well (which in fact behaves even worse WRT this issue). Please let us know if we can help in any way, |
Thanks I will try that..
I just didn't have time yet to investigate further. I hope I will get some time in the next days... |
Activity has decreased lately, probably all of us being quite busy right now...
It seems to depend on map and device being used. On my two devices (one with 2024.04.25 release, one with selected dev builds as needed), UnifiedMap is quite stable and performance is ok (with the number of caches I normally have on a map, that is). A few quirks happen from time to time, but also not really reproducible for me, which makes it hard to pursue the bugs. For the "individual route" issues I have an idea what to try next, but haven't found the time yet to do so, but for the rest of the more annoying bugs I'm currently at loss how to investigate further. |
|
@moving-bits I can reproduce on my device, running from Android-studio, so I can debug and try to add logs if I found some points of interest... |
|
Another observation I made today: UM crashes immediately, when you perform any action (e. g. panning) while the refresh marker (the pulsing line between map and header) still indicates activity. I didn't notice this so clearly before, because under Android 10 this line is way darker and much narrower, in fact almost invisible. But with Android 14, it's almost "intrusive", so I've only now really noticed both, the line and the correlation between line and crashes. Perhaps this helps ... |
This is truly strange. I've just cross-checked with my two physical devices (Samsung, running on Android 14, and Motorola, running Android 13): Both seem to have no problems with panning while still loading caches, both in live map activated as in offline mode. Can you post a logcat (or send to support, whatever you prefer)? |
|
I got some time today to debug a little bit... It seems to be dependent on I had one crash, where the While debugging (with breakpoints on) it seems to me, that it crashes less often - so probably a timing / memory related problem? I have often following entries in the log, but even if Didn't check with the different modes for compact-icon-mode yet ... The last logs are whether I will continue this evening or tomorrow... Any ideas where to put additional logs are appreciated ;-) |
PR #15742 adds a catching of exceptions around the Atlas-access-code of markersymbol. It also adds logging for exceptions in those cases. I put the PR against release since if this is the problematic area then release branch would also be affected. |
|
I tried with PR #15742, still have the crash but unfortunately no exceptions related to Atlas-access-mode logged 🤔 |
That's bad. If Atlas is really the issue, this would mean that it doesn't even throw an exception on problems. Let's hope the issue lies somewhere else.... |
|
FYI: |
Yes, it is, badly - UM is still completely unusable for us with all nightlies since 2024.05.12-NB-a1dd1ef. |
|
After scrolling through this issue I found, that I might also experience it on my tablet device.
Anything I can do to help digging down? |
|
Which is in fact exactly what happens over here with
both usually used with offline OSM from OpenAndroMaps. What I BTW found interesting was @murggel's finding
Any chance for mortal humans like me to switch this off, i. e. create a scenario or change a setting which results in a scenario where Not to permanently disable it, but because I'm curious if this is the hulk over here, too ... |
|
Unfortunately I have currently not so much time to dig deeper into it - I guess it needs more places to catch an exception and see ehat happened - but I can probably provide a PR for switching using atlas on/off... |
You can manuall create the setting using This will lead to VTM rendering EVERY symbol on the map the same! (not only cache markers but also e.g. the position marker) So it is clearly for testing purposes only. |
|
Thx - worked. Although creating the variable was a somewhat confusing process: It was of course no problem to create the variable, even setting it's value seemed to work like a charm, but after the value was assigned, resp. the value dialog was closed, the variable simply vanished. Seemingly. It was not visible in the settings. So I created/set it about three times, IIRC, already believed that I probably don't have permission to change the configuration ... but after leaving and re-entering the settings list again, it was finally there. Strange. However, learned two more things:
BTW: After that I switched back to |
|
Due to @MagpieFourtyTwo and other's test results: |
|
Unfortunately I have still not seen any reasonable / relevant logs after crashing, while debugging it seems to me, that I have to move around a lot more before the crash occurs. In logcat there are logs like |
As it's always not only c:geo that crashes, but even Bluetooth and WiFi connections drop, some background apps get killed (like Tasker and MyPhoneExplorer client) plus widgets get cleared, I could imagine that even fflush does not succeed, either.
Perhaps it's a runtime/sync/memory problem, which takes longer to occur if c:geo gets some more time to breath. However, I think I nailed a scenario where c:geo crashes pretty reproducible, even on more performant hardware with more RAM: Just visit a "cache polluted area" ;) zoom out until >500 caches are in view and then try to pan and zoom ... While behavior differs a bit depending on used device:
In both cases other apps are affected, too, even Bluetooth and WiFi connections drop for about half a second, as said before. |
|
I think we seriously have to consider moving away from VTM and "back to mapsforge". Progress for map rotation looks promising imho, see eg #15743 |
|
Agreed. Or if it's not too much effort in the long run, provide "experimental" VMT and mapsforge in parallel, with mapsforge being the default. Adding mapsforge into unified map should actually be not too much effort IMHO. |
Describe your problem!
On panning / zooming the map (UnifiedMap), the map crashes.
Sometimes it needs 2 or 3 steps - probably related to the visible cash count?
even crashes on just opening the map...
does not crash, if only a few cashes are visible
How to reproduce?
Open UnifiedMap around Stuttgart
Pan / zoom out
Actual result after these steps?
c:geo crashes
Expected result after these steps?
no crahs
Reproducible
Yes
c:geo Version
2024.05.12-NB-a1dd1ef
System information
No response
Additional Information
The text was updated successfully, but these errors were encountered: