60.0-alpha2 crashes on Android 6 if GPS is enabled #6001
Labels
bug
feedback required
more info is needed, issue will be likely closed if it is not provided
upstream
result from an upstream issue
Comments
|
That phone does not have screen recorder, so had to use another phone to record it... small_20241104_180827_SC_crashes.mp4and here is SCEE on the same area with about same amount of data loaded, working just fine: small_20241104_180332_SCEE_works.mp4I switched between several times, and always SC 6.0-alpha2 crashed, and SCEE 59.1 worked. |
|
Don't know if it helps, but I've tried looking up that error - there were not much matches, but those that I found always seemed (e.g. android/sunflower#519 or material-components/material-components-android#661) related to some "0dp" fix MaterialComponents thingies like solved here: https://stackoverflow.com/questions/36115934/android-opengl-error-during-camera-animation |
|
Uff, a crash in native code, so we can not really fix this here, only try to avoid it occuring, i.e. working around it. Are you able to post the stack trace here? |
Yeah, but since it doesn't crash in SCEE 59.1, I'd guess SC 59.1 was also fine, so it should be possible to isolate and then change the factor leading up to the crashes. Do you want me to some more tests on that device?
Here it is: |
|
Thanks! Hmm... not helpful, though. So the crash does not happen when location is off? At the moment I have no idea what could cause this. If your view is not glued to the location, the following things should be different as compared to having no location at all:
Since you are currently the only one who can reproduce this, I fear you are currently the only one who can dig down deeper what exactly is causing the crash. So, you could comment out some stuff that is happening when the app has location and run the app again to see if the crash is still reproducible then. |
westnordost
added
the
feedback required
mnalis
added a commit
to mnalis/StreetComplete
that referenced
this issue
Nov 19, 2024
as suggested in streetcomplete#6001 (comment)
|
The debug effort so far:
logGit bisect log: 6001-bisectlog1.txt I will try digging some more, and try to comment out some things (if I can figure out which ones) ... If anybody has any more hints on what to try, let me know. |
|
👍 You could add a log to Also, what changed is the version of compose. Maybe compose has a bug. You could try to downgrade Compose to see if the issue also appears for an older version of compose. |
|
I've tried reverting to previous compose versions used in working 59.3, but it did not help. It seems it crashes even if it never got data from the Internet, and that it crashes only when current location pointer gets off the screen. Below are the detailed steps, logs, and video. Any hint what to try next?
Here is the log and the video: small_Screenlog_crash_left_20241120_1930.mp4 |
|
Okay, we are getting closer. In MainScreen, in line 372 or so, the PointerPinButton is added. What I find interesting, is that in your video, the display of that button flickers. What is happening here? Is the calculated intersection alternating between null and a proper value? You could log that to see what the values are. Also, if the crash never happens when it is at the top of the screen, maybe it has something to do with positioning the pointer pin button? You could replace the Modifier with |
|
BTW, I've noticed following in the log, which seems related to StreetComplete debug build: Is that perhaps interesting?
I've addeded that debug and it displays the following when pointers go up and flickers: The values in the log look normal to me:however, it seems that it flickers because on some movements it doesn't get drawn, even if values look normal, e.g. here: Values leading to the crash also look normal if I pan the screen so icon goes off on the left edge of the screen: |
Yes. In fact, with that change, it now crashes even if it goes to the top of the screen: |
No.
Okay, interesting. So, the calculation is fine, and the calculation isn't "flickering". But for some reason, it's not drawn every second-or-so UI update. That'd be an issue on its own, but maybe it is connected.
What do you mean? It shouldn't go to the top of the screen but be in the center of the screen always. |
Yeah, that extra pointer which points towards the current location (blue dot in white teardrop) is indeed pinned in the center of the screen instead pinned to one of the borders (as it was before), but when the original location icon (blue circle with direction-view-cone) goes on the top of the screen, it crashes (while location icon going up was only survivable direction before this centering-change) Here is a video, perhaps it will be clearer: small_Screenrecorder-2024-11-23-23-07-08-628.mp4 |
|
Weird, how can it crash now when less things are done? (I.e. no positioning is done) Regarding the flickering, you put the log at the position where |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While trying to help debug performance issues in #5994 (comment), I've encountered almost immediate crashes with this phone.
I thought of #5954 / maplibre/maplibre-native#2206, but:
Abort message: Error: Spot pair overlow!!! used 205, total 116)How to Reproduce
Expected Behavior
I'd expect it to not crash. Also of note:
Versions affected
60.0-alpha2, Android 6.0.1 on Xiaomi Redmi Note 3
The text was updated successfully, but these errors were encountered: