Memory Allocation Failure / Crash on Startup

[nikhiljha]

While running with grapheneOS, the app crashes on startup. I think I've narrowed this down to the hardened malloc implementation that grapheneOS uses, indicating memory management issues with the com.mapzen.tangram package.

12-02 10:04:08.935 26927 26927 E AndroidRuntime: FATAL EXCEPTION: main
12-02 10:04:08.935 26927 26927 E AndroidRuntime: Process: de.westnordost.streetcomplete, PID: 26927
12-02 10:04:08.935 26927 26927 E AndroidRuntime: java.lang.RuntimeException: Unable to create a native Map object! There may be insufficient memory available.
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.mapzen.tangram.MapController.<init>(MapController.java:163)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.mapzen.tangram.MapView.getMapInstance(MapView.java:276)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.mapzen.tangram.MapView.initMapController(MapView.java:173)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.mapzen.tangram.MapView$1.onLibraryReady(MapView.java:120)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.mapzen.tangram.MapView$1InitTask.onPostExecute(MapView.java:236)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.mapzen.tangram.MapView$1InitTask.onPostExecute(MapView.java:224)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at android.os.AsyncTask.finish(AsyncTask.java:771)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at android.os.AsyncTask.access$900(AsyncTask.java:199)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:788)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:106)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:223)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:7656)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.android.internal.os.ExecInit.main(ExecInit.java:43)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
12-02 10:04:08.935 26927 26927 E AndroidRuntime:        at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:399)

How to Reproduce

1. From grapheneOS, launch the app.

Versions affected
Tested on StreetComplete v26.2, v27 from F-Droid, grapheneOS 2020-11-27 (Android 11)

Potential easy fix(?)
It looks like they rewrote some of the relevant code in tangram recently (see tangrams/tangram-es@c4b0245), maybe upgrading the package will fix the issue.

[westnordost]

We are using the newest available version of tangram-es. Best report this problem directly into the tangram-es issue tracker. I'll close this here as this is not solvable in this repo

[westnordost]

Quick link to their issue tracker: https://github.com/tangrams/tangram-es/issues/

[nikhiljha]

Thanks! Created a new issue here: tangrams/tangram-es#2215

[nikhiljha]

I tried to build StreetComplete with changes to debug the issue, but I ran into this google/dagger#1339 issue, which is caused by using JDK != 8 (?), but Android Studio refuses to load JDK < 11. What setup do you use to build this @westnordost ?

[westnordost]

Looking at the project properties, Android Studio is using the JDK that is shipped together with Android Studio in my setup.

[nikhiljha]

Oh no, the version I built myself runs without issue. Only the build on F-Droid is broken. :(

This issue keeps getting more cursed.

[westnordost]

Hm!

The version you built will be a debug version. Try building a release version (I think you need to sign it with an own key then) and see if you can reproduce the crash with that.

[nikhiljha]

Ah right, the release version crashes with the expected error. Maybe the compiler is optimizing something away when it's built in release mode. 🤔

Also kinda suspect proguard/r8, although Cannot fit requested classes in a single dex file (# methods: 73070 > 65536) so I can't check when they're turned off.

[westnordost]

Well you could try to turn on multidex to solve that particular problem. It is also possible to "debug" proguard/r8, i.e. output what exactly it throws away. I think it was some parameter you add to the proguard config that does that.