leaks de.westnordost.streetcomplete.MainActivity instance

[matkoniecz]

Leak detection enabled in Dev mode regularly detects that Main activity is leaked, but as it was happening in my fork build I was not reporting it.

Today I confirmed that it happens also in Dev build of unmodified SC.

Is it something unimportant (leaked memory is below 100kb, usually around 30kb and not very often), or something already investigated and turned out to be unfixable?

Would it be useful to provide loss produced by leak detection tool?

[westnordost]

Yes, it would.

[matkoniecz]

posted to https://gist.github.com/matkoniecz/b2c28afaf9e9e9378624cc812e9d65e8 (485 KB one was unusually large)

First was triggered by activities like rotating phone, browsing quests (without solving them) and switching to other apps without other activity that seems relevant

Second was triggered by activities like browsing quests (without solving them) and switching to other apps without other activity that seems relevant

[matkoniecz]

leak was triggered on SC trunk, revision 9f25eeb

[westnordost]

Actually, this screenshot from the LeakCanary app is the most useful thing. Usually, it is immediately apparent from the "stack trace" what is the problem.
That trace seems to be included in the log you posted as well, if I understand it right...

In de.westnordost.streetcomplete.debug:4.0-beta1:400.
* de.westnordost.streetcomplete.MainActivity has leaked:
* GC ROOT com.mapzen.tangram.MapController.mapView
* references android.opengl.GLSurfaceView.mContext
* leaks de.westnordost.streetcomplete.MainActivity instance

then it seems the leak is caused by tangram's MapView. I checked if the MapFragment correctly forwards the calls to onDestroy, onResume, onPause etc. to the MapView. It does, so there is no error in StreetComplete.
If the leak is reproducable, it should be reported to Tangram-Es.