Closed mnalis closed 8 hours ago
That phone does not have screen recorder, so had to use another phone to record it... Here is SC crashing after few seconds of panning:
https://github.com/user-attachments/assets/a124772b-228f-4c66-89bb-c2862e428c66
and here is SCEE on the same area with about same amount of data loaded, working just fine:
https://github.com/user-attachments/assets/cf53aaca-7641-4f72-9859-9c61f6b5ab86
I 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. https://github.com/android/sunflower/issues/519 or https://github.com/material-components/material-components-android/issues/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?
Uff, a crash in native code, so we can not really fix this here, only try to avoid it occuring
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?
Are you able to post the stack trace here?
Here it is:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Xiaomi/kenzo/kenzo:6.0.1/MMB29M/V10.2.1.0.MHOMIXM:user/release-keys'
Revision: '0'
ABI: 'arm64'
pid: 23297, tid: 23358, name: hwuiTask2 >>> de.westnordost.streetcomplete <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'Error: Spot pair overflow!!! used 171, total 108'
x0 0000000000000000 x1 0000000000005b3e x2 0000000000000006 x3 0000000000000000
x4 0000000000000000 x5 0000000000000001 x6 0000000000000000 x7 0000000000000000
x8 0000000000000083 x9 0000007fad6fe012 x10 0000000000000000 x11 0000007fad6fd000
x12 0000007fad6e8090 x13 0000000000000000 x14 0000007fad6fd000 x15 0000007fad6e8158
x16 0000007fb080a6a8 x17 0000007fb07ccbdc x18 0000007fad6fd000 x19 0000007f8a490510
x20 0000007f8a490450 x21 0000000000000000 x22 0000000000000006 x23 00000000000000ab
x24 000000000000001b x25 00000000000000ab x26 00000055b4297760 x27 0000007f8a48f290
x28 00000000000000ab x29 0000007f8a48e5a0 x30 0000007fb07ca378
sp 0000007f8a48e5a0 pc 0000007fb07ccbe4 pstate 0000000020000000
backtrace:
#00 pc 000000000006abe4 /system/lib64/libc.so (tgkill+8)
#01 pc 0000000000068374 /system/lib64/libc.so (pthread_kill+68)
#02 pc 00000000000212f8 /system/lib64/libc.so (raise+28)
#03 pc 000000000001ba98 /system/lib64/libc.so (abort+60)
#04 pc 000000000000d328 /system/lib64/libcutils.so (__android_log_assert+236)
#05 pc 000000000006f168 /system/lib64/libhwui.so
#06 pc 0000000000074d14 /system/lib64/libhwui.so
#07 pc 0000001500000087 <unknown>
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.
E.g. search for intersection
in MainScreen
to find what to comment out to make the location pointer pin dissapear. The location dot on the map is displayed in CurrentLocationMapComponent
. See also MainMapFragment.onLocationChanged
. You could add a Log.e("LOCATION", "Got a new Location!")
there to see if the crash happens at exactly the time a new location is being received from the system.
The debug effort so far:
git bisect
to get more precise commit which introduces the error, due to compilation errors, the best I can do is limit it to one of those 7 commits:There are only 'skip'ped commits left to test. The first bad commit could be any of: 2c4cb49c221de0b241bb233bd503554aedbc2f33 50abfbba61e69f615dc5ae19bf7074ceb4995970 1f8c5185b38e4137f89add4893b7e7e8606e740f a095b21464e398e90986fca060206936c621e844 e3c8a48b9535d3c237dfb526c6d7aa4888d1c65d f8bb5b1b1e873bf0f19992237e0858a3a2498127 8d2dde061ed910d382463518da5f7daf4f23cf13 We cannot bisect more!
Git 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 onNewIntent
, too, because this is most of what changed in the commits you mentioned.
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?
+
/ -
zoom buttons seems to work and does not crash.MainActivity.kt:onNewIntent()
log did not get loggedHere is the log and the video: crash_left_20241120_1930.txt
https://github.com/user-attachments/assets/14967a73-8b3e-418a-ac42-6af25b1f7bbc
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
modifier = Modifier.align(Alignment.Center),
to make it always display at the center of the screen. Is the crash still reproducible, then?
BTW, I've noticed following in the log, which seems related to StreetComplete debug build:
11-21 00:50:13.060 27806 27806 E Mbgl : {tcomplete.debug}[JNI]: Error setting property: symbol-sort-key layer doesn't support this property
11-21 00:50:13.060 27806 27806 E Mbgl : {tcomplete.debug}[JNI]: Error setting property: icon-allow-overlap layer doesn't support this property
11-21 00:50:13.060 27806 27806 E Mbgl : {tcomplete.debug}[JNI]: Error setting property: icon-ignore-placement layer doesn't support this property
Is that perhaps interesting?
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.
I've addeded that debug and it displays the following when pointers go up and flickers:
however, it seems that it flickers because on some movements it doesn't get drawn, even if values look normal, e.g. here:
11-21 00:51:15.610 27806 27806 E POINTERPIN: Creating PointerPinButton rotate=-0.38943258 xDp=177.90651.dp yDp=24.0.dp
11-21 00:51:15.644 27806 27806 E POINTERPIN: Creating PointerPinButton rotate=-0.32861656 xDp=178.23344.dp yDp=24.0.dp
<!-- the icon wasn't displayed at all here, and I stopped touching the screen
for dozen seconds and it still wasn't displayed.
When I then started panning again below, the icon appeared again and continued flickering as I panned -->
11-21 00:51:18.982 27514 27570 E chromium: [ERROR:aw_gl_functor.cc(101)] Received unexpected kModeProcessNoContext
11-21 00:51:23.995 27514 27570 E chromium: [ERROR:aw_gl_functor.cc(101)] Received unexpected kModeProcessNoContext
11-21 00:51:24.029 27806 27806 E POINTERPIN: Creating PointerPinButton rotate=-0.32877365 xDp=178.23262.dp yDp=24.0.dp
11-21 00:51:24.069 27806 27806 E POINTERPIN: Creating PointerPinButton rotate=-0.32906052 xDp=178.2311.dp yDp=24.0.dp
Values leading to the crash also look normal if I pan the screen so icon goes off on the left edge of the screen:
11-21 01:06:05.244 28251 28251 E POINTERPIN: Creating PointerPinButton rotate=263.64233 xDp=0.0.dp yDp=352.05554.dp
11-21 01:06:05.325 28251 28251 E POINTERPIN: Creating PointerPinButton rotate=263.4318 xDp=0.0.dp yDp=352.72546.dp
11-21 01:06:05.358 28251 28251 E POINTERPIN: Creating PointerPinButton rotate=263.42114 xDp=0.0.dp yDp=352.7594.dp
11-21 01:06:05.372 28251 28308 F OpenGLRenderer: Error: Spot pair overflow!!! used 186, total 116
11-21 01:06:05.372 28251 28308 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 28308 (hwuiTask1)
11-21 01:06:05.392 28251 28251 E POINTERPIN: Creating PointerPinButton rotate=263.35764 xDp=0.0.dp yDp=352.96158.dp
11-21 01:06:05.479 599 599 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
11-21 01:06:05.479 599 599 F DEBUG : Build fingerprint: 'Xiaomi/kenzo/kenzo:6.0.1/MMB29M/V10.2.1.0.MHOMIXM:user/release-keys'
11-21 01:06:05.480 599 599 F DEBUG : Revision: '0'
11-21 01:06:05.480 599 599 F DEBUG : ABI: 'arm64'
11-21 01:06:05.481 599 599 F DEBUG : pid: 28251, tid: 28308, name: hwuiTask1 >>> de.westnordost.streetcomplete.debug <<<
11-21 01:06:05.481 599 599 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
You could replace the Modifier with modifier = Modifier.align(Alignment.Center), to make it always display at the center of the screen. Is the crash still reproducible, then?
Yes. In fact, with that change, it now crashes even if it goes to the top of the screen:
11-21 01:17:12.031 29583 29583 E POINTERPIN: Creating PointerPinButton rotate=4.4195194 xDp=203.80486.dp yDp=24.0.dp
11-21 01:17:12.077 29583 29583 E POINTERPIN: Creating PointerPinButton rotate=4.737622 xDp=205.52582.dp yDp=24.0.dp
11-21 01:17:12.093 29583 29583 E POINTERPIN: Creating PointerPinButton rotate=4.800473 xDp=205.86604.dp yDp=24.0.dp
11-21 01:17:12.111 29583 29583 E POINTERPIN: Creating PointerPinButton rotate=4.8631606 xDp=206.20543.dp yDp=24.0.dp
11-21 01:17:12.129 29583 29583 E POINTERPIN: Creating PointerPinButton rotate=4.9864388 xDp=206.87305.dp yDp=24.0.dp
11-21 01:17:12.145 29583 29583 E POINTERPIN: Creating PointerPinButton rotate=5.01031 xDp=207.00238.dp yDp=24.0.dp
11-21 01:17:12.152 29583 29638 F OpenGLRenderer: Error: Spot pair overflow!!! used 206, total 112
--------- beginning of crash
11-21 01:17:12.152 29583 29638 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 29638 (hwuiTask1)
11-21 01:17:12.161 29583 29583 E POINTERPIN: Creating PointerPinButton rotate=5.0433683 xDp=207.18146.dp yDp=24.0.dp
11-21 01:17:12.255 599 599 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
11-21 01:17:12.256 599 599 F DEBUG : Build fingerprint: 'Xiaomi/kenzo/kenzo:6.0.1/MMB29M/V10.2.1.0.MHOMIXM:user/release-keys'
11-21 01:17:12.256 599 599 F DEBUG : Revision: '0'
11-21 01:17:12.256 599 599 F DEBUG : ABI: 'arm64'
11-21 01:17:12.256 599 599 F DEBUG : pid: 29583, tid: 29638, name: hwuiTask1 >>> de.westnordost.streetcomplete.debug <<<
11-21 01:17:12.256 599 599 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
11-21 01:17:12.295 599 599 F DEBUG : Abort message: 'Error: Spot pair overflow!!! used 206, total 112'
11-21 01:17:12.295 599 599 F DEBUG : x0 0000000000000000 x1 00000000000073c6 x2 0000000000000006 x3 0000000000000000
11-21 01:17:12.296 599 599 F DEBUG : x4 0000000000000000 x5 0000000000000001 x6 0000000000000000 x7 0000000000000000
11-21 01:17:12.296 599 599 F DEBUG : x8 0000000000000083 x9 0000007f88f10012 x10 0000000000000000 x11 0000007f88f0f000
11-21 01:17:12.296 599 599 F DEBUG : x12 0000007f88efa090 x13 0000000000000000 x14 0000007f88f0f000 x15 0000007f88efa158
11-21 01:17:12.296 599 599 F DEBUG : x16 0000007f8c01c6a8 x17 0000007f8bfdebdc x18 0000007f88f0f000 x19 0000007f5f53f510
11-21 01:17:12.296 599 599 F DEBUG : x20 0000007f5f53f450 x21 0000000000000000 x22 0000000000000006 x23 00000000000000ce
11-21 01:17:12.296 599 599 F DEBUG : x24 000000000000001b x25 00000000000000ce x26 00000055a64e9a40 x27 0000007f5f53e290
11-21 01:17:12.297 599 599 F DEBUG : x28 00000000000000ce x29 0000007f5f53d560 x30 0000007f8bfdc378
11-21 01:17:12.297 599 599 F DEBUG : sp 0000007f5f53d560 pc 0000007f8bfdebe4 pstate 0000000020000000
11-21 01:17:12.300 599 599 F DEBUG :
11-21 01:17:12.300 599 599 F DEBUG : backtrace:
11-21 01:17:12.301 599 599 F DEBUG : #00 pc 000000000006abe4 /system/lib64/libc.so (tgkill+8)
11-21 01:17:12.301 599 599 F DEBUG : #01 pc 0000000000068374 /system/lib64/libc.so (pthread_kill+68)
11-21 01:17:12.301 599 599 F DEBUG : #02 pc 00000000000212f8 /system/lib64/libc.so (raise+28)
11-21 01:17:12.301 599 599 F DEBUG : #03 pc 000000000001ba98 /system/lib64/libc.so (abort+60)
11-21 01:17:12.301 599 599 F DEBUG : #04 pc 000000000000d328 /system/lib64/libcutils.so (__android_log_assert+236)
11-21 01:17:12.301 599 599 F DEBUG : #05 pc 000000000006f168 /system/lib64/libhwui.so
11-21 01:17:12.301 599 599 F DEBUG : #06 pc 0000000000074d14 /system/lib64/libhwui.so
11-21 01:17:12.302 599 599 F DEBUG : #07 pc 000000030000008b <unknown>
11-21 01:17:12.915 14616 29661 W ActivityManager: Force finishing activity de.westnordost.streetcomplete.debug/de.westnordost.streetcomplete.screens.main.MainActivity
Is that perhaps interesting?
No.
intersection logs / flickering
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.
Yes. In fact, with that change, it now crashes even if it goes to the top of the screen:
What do you mean? It shouldn't go to the top of the screen but be in the center of the screen always.
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:
https://github.com/user-attachments/assets/84c76433-8843-4ad0-83b6-807a8bc0ba77
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 intersection
is already known to not be null
. So does that mean that every second or so time, intersection
is null? (If yes, we should get to the bottom of this. Why is no intersection found?)
Weird, how can it crash now when less things are done? (I.e. no positioning is done)
I have no idea :man_shrugging:
However, when I remove PointerPinButton
call completely (https://github.com/mnalis/StreetComplete/commit/6915963c233a9cc135145745c5b48ade786c75a7) then the app seems to work just fine:
log_SC_removed_PointerPinButton-6915963.txt
https://github.com/user-attachments/assets/9d604c54-4835-470a-86e1-5481836e5966
Any other ideas what I could try?
Regarding the flickering, you put the log at the position where intersection is already known to not be null. So does that mean that every second or so time, intersection is null? (If yes, we should get to the bottom of this. Why is no intersection found?)
I'm totally out of my depth here (as I don't even understand how those things get called and by who) so can't even say if your question is rhetorical question or am I supposed to try something here to provide the answer, sorry. :sweat_smile:
I'm willing to try any idea you have and test and provide output, but I have no idea how/where to add debug points...
However, when I remove
PointerPinButton
call completely (https://github.com/mnalis/StreetComplete/commit/6915963c233a9cc135145745c5b48ade786c75a7) then the app seems to work just fine
I've managed to find another datapoint: it doesn't crash if I leave PointerPinButton
call in, but force rotate=0.0f
or rotate=45.0f
(instead of original rotation.toFloat()
) -- regardless of whether I use modifier.absoluteOffset
or modifier.align(Alignment.Center)
!
Ok, this is getting more and more bizzare. I've done three tests, all the same with PointerPinButton
in the center, but instead of using actual angle, they had different rotation
value hardcoded (that was the only variable changed between them). Those tests resulted in 3 different behaviours:
rotation=45.0f
(https://github.com/mnalis/StreetComplete/commit/f3e77d31f9198caba2446da54b1ddd5a8b3f1c98) - everything works normally, pin is displayed at 45 degrees angle (0.0f
also works, for example)
rotation=75.0100f
(https://github.com/mnalis/StreetComplete/commit/7e1fcfefbe85ad2a1a7cd0d9a30f5150fef0cebf) - doesn't crash, but no pin is displayed! (could that also explain flickering?)
rotation=75.02551f
(https://github.com/mnalis/StreetComplete/commit/b0f689e270d7db2210b0fad34f357302190f5788) - crashes
Okay, let's try two things. First, revert to the current master state, then add
1.
Log.d("MNALIS", intersection?.let { "a=${it.angle}, x=${it.position.x}, y=${it.position.x}" } ?: "null")
just before
intersection?.let { (offset, angle) ->
(you need to add import de.westnordost.streetcomplete.util.logs.Log
at the top)
The log output, does it log "null" often/sometimes? Or always an angle plus position?
Do you have Android Studio installed?
also, starting from master, remove line 67 and line 57 in PointerPinButton.kt (the stuff with the shape). Does this solve the crash?
starting from master, remove lines 61-65 in PointerPinButton.kt. Does this solve the crash?
Log.d("MNALIS", intersection?.let { "a=${it.angle}, x=${it.position.x}, y=${it.position.x}" } ?: "null")
The log output, does it log "null" often/sometimes? Or always an angle plus position?
OK, done in https://github.com/mnalis/StreetComplete/commit/c77c47cea60a65356914f60809c4bf2680c5c163. It seems to display "null" very often, but it seems to me only while my location is still inside of the screen. When I get out of the screen so teardrop-pin is created, it seems to only contain positive values until it crashes, e.g.
- So, apparently the crash happens due to the rotation of the widget. If you just set the rotation to something constant, e.g. 0, then everything else works?
Depends on the constant, see https://github.com/streetcomplete/StreetComplete/issues/6001#issuecomment-2506709569 for examples. Yes, with 0
(and 45
) everything works normally, but constant 75.02551
crashes, and constant 75.0100
doesn't display the pin (but doesn't crash either).
Do you have Android Studio installed?
No.
- also, starting from master, remove line 67 and line 57 in PointerPinButton.kt (the stuff with the shape). Does this solve the crash?
Yes, (https://github.com/mnalis/StreetComplete/commit/d98839309e076925a85b0c7e9f660e936106c5ee) solves the crash (the pin is displayed as blue circle in white box)
- starting from master, remove lines 61-65 in PointerPinButton.kt. Does this solve the crash?
Yes, (https://github.com/mnalis/StreetComplete/commit/2500c76d769afcf7ca2e9aa9315ef375cc7cafde) also solves the crash (the pin looks normal blue dot in white teardrop and even seems to rotate correctly, but it is always placed at top-left corner no matter which side of the screen I moved the GPS dot out)
What, either of 3 and 4 solves the crash? Are you sure?
What, either of 3 and 4 solves the crash? Are you sure?
Yes, either of those changes avoids the crash.
Here is video of only change 3 (https://github.com/mnalis/StreetComplete/commit/d98839309e076925a85b0c7e9f660e936106c5ee):
https://github.com/user-attachments/assets/946243d2-0e36-4153-9d9e-22cf23580f4d
And here is video of only change 4 (https://github.com/mnalis/StreetComplete/commit/2500c76d769afcf7ca2e9aa9315ef375cc7cafde):
https://github.com/user-attachments/assets/8354c3c1-1705-434c-b695-1d9776522201
Looking at the code and searching the net, I've found a workaround; forcing elevation = 0.dp
in PointerPinButton()
:
Doing that fixes the crash, at only the cost of not displaying slight shadow on that teardrop pin.
It seems to be an known issue in some Android versions, see https://stackoverflow.com/a/37249265/2600099
So, shadow can be disabled always there, or only when problematic Android version is detected, like e.g. here: https://github.com/material-components/material-components-android/commit/3c3ac61c9126a7b97da7e10324be163c11257e53
Would you like me to make a PR @westnordost, and if so, which solution would you prefer?
Alright, I'll try that, thank you for your relentless testing!
Alright, I'll try that, thank you for your relentless testing! Do you have an Android 7 device with which you can reproduce the issue? Otherwise, I will jsut add the exception for Android 6
Do you have an Android 7 device with which you can reproduce the issue?
Unfortunately not, only Android 7.1 device I have does not support GLES 3.0 so it doesn't really display anything in recent SC versions (https://github.com/streetcomplete/StreetComplete/issues/6029)... I've tried moving screen around blindly on that device and it didn't seem to crash, but that is more likely because MapLibre doesn't work at all there (as other things looks fishy too), then a confirmation the bug doesn't exist in Android 7... :man_shrugging:
Next device up which I have is Android 9, and that does not have the bug...
While trying to help debug performance issues in https://github.com/streetcomplete/StreetComplete/issues/5994#issuecomment-2453041453, I've encountered almost immediate crashes with this phone.
I thought of https://github.com/streetcomplete/StreetComplete/issues/5954 / https://github.com/maplibre/maplibre-native/issues/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