Frequent Crashes, usually when zooming/panning, usually soon after app start

[Jakeory1]

The app simply closes. Sometimes I will see the ("App not responding! Force Stop?") banner from Android pop up for a ms before the app closes.
Once, I saw the apps 'Send Email to report crash" banner pop up on restart but the app crashed too soon to click it.
It usually takes a little longer to crash if the app has been open in the background for a while.
Staying zoomed in to the default zoom level makes crashes infrequent enough for the app to almost be usable.
This issue appears to be connected to the amount of solved (or uploaded) quests (possible just if the are close to your location), or the time the app has been used in total. I believe this because when I started using the app a couple of days ago I did not have any issues, I remember a crash or 2 on my second trip yesterday, and now the app is unusable for me.
In case the uploaded quest are an issue:
I uploaded them manually at the end of each trip and I did not notice crashes getting more frequent during a trip.

How to Reproduce

1. Possible do 200-500 quests in your area or use the app for a few hours.(?)
2. Force stop the applications via Android Setting if the app is running.
3. Zoom and pan the map for a few seconds till the app crashes.
4. When starting the app back up (without force stopping), zoom/pan again and it will crash again.

Versions affected
SC v53.3
Android 13 (GrapheneOS, in case that's relevant)

I am happy to provide more information as needed. This is my first bug report tho, so I might need a small explanation on where to find the information.

[Jakeory1]

Temporary Fix:

1. Delete all app data in Android Setting (Clear Storage, Clear Cache)
2. Use SC as usual, but do NOT log in.
3. Log in and upload the changes you made (I left the setting on auto upload and would recommended that since I do not know whether the app might crash before you can manually upload)
4. The app will crash on the next zoom/pan.
5. Go back to step 1 for your next survey.

Bug Report
I got this report after a crash that accursed after using the obove strategy. My screen froze and I was able to click Androids "App not responding" (or whatever its called) to get the following bug report, which I deleted the last section that basically shows all my apps from:

type: ANR
osVersion: google/sunfish/sunfish:13/TQ3A.230705.001/2023071100:user/release-keys
package: de.westnordost.streetcomplete:5304
process: de.westnordost.streetcomplete

activity: de.westnordost.streetcomplete/.screens.MainActivity
cause: ANR Input dispatching timed out (7bdce48 de.westnordost.streetcomplete/de.westnordost.streetcomplete.screens.MainActivity (server) is not responding. Waited 5000ms for MotionEvent)
info: ANR in de.westnordost.streetcomplete (de.westnordost.streetcomplete/.screens.MainActivity)
PID: 23906
Reason: Input dispatching timed out (7bdce48 de.westnordost.streetcomplete/de.westnordost.streetcomplete.screens.MainActivity (server) is not responding. Waited 5000ms for MotionEvent)
Parent: de.westnordost.streetcomplete/.screens.MainActivity
ErrorId: c9bf3fc9-59a6-4e93-a87a-5e245e65c967
Frozen: false
Load: 1.58 / 1.42 / 1.11
----- Output from /proc/pressure/memory -----
some avg10=0.00 avg60=0.03 avg300=0.04 total=7942364
full avg10=0.00 avg60=0.01 avg300=0.01 total=5163799
----- End output from /proc/pressure/memory -----

If any part of the last bit, that I took away, is relevant, please aks me for the specific part you are interested in.

[westnordost]

Well, I think think it is very relevant that it is GrapheneOS for it comes with a security feature that make apps rather crash than allowing apps to write to memory that already has been deallocated (if I remember correctly). This is an error that can easily happen on race conditions, i.e. there is a bug in concurrency, but only in native (e.g. C++) code.

GrapheneOS is all about security, and writing to memory that already has been deallocated can be a security vulnerability, hence this feature seems to be enabled by default for all apps.

This app uses a third party free and open source library implemented in C++ (named tangram-es) from which this issue is originating. However, sadly, the library is not maintained anymore, so it would be pointless to report this issue in their issue tracker.

This ticket contains more information about this and a possible workaround for it in #4277 (comment) .

Furthermore, @Helium314 explored replacing the non-maintained library with a library named MapLibre, but work on it is frozen for the moment. See #3123

[Jakeory1]

@westnordost Thank you so much! <3