Android App Support crashes after starting because VM runs out of heap

Bug Reports
21

Indeed I’m noticing now this is not even the main problem thread, even though title describes a very similar symptom.

[10 III] [5.0.0.71] Android App Support does not start when “Start Android App Support when device starts” is enabled is probably the one that I’m referring to, and it also has at least 5 other :thread:s linked.

1 Like
22

Thanks. There’s definitely something going on, but not all people report about the loop/circling, and afaics nobody checked if it is indeed a (near) endless loop, and very few properly troubleshot the problem on their device.

  • Enable persistent logging to get better logs
  • Remove all user-added Android stuff, and (if that helps) start adding it back one by one
  • use logcat as seen in this post

Etc.

Is it possible it isn’t even the systemd service that’s crash-looping, but the startup script itself, or some part of it? That would be easy to see from persistent logs.

23

It’s near endless (hours at least and I never noticed it resolving by itself) for me and it looks like it’s triggered by switching between 4G/5G and WiFi on my Xperia 10 III.

1 Like
24

This was fixed by 5.0.0.73, see: [Release notes] Tampella 5.0.0.73 - Early Access!

2 Likes
25

And I have to reopen the issue, again… Something crashed and now it no longer starts.
Well, it starts, but then the runtime crashes and gets into the loop again.
I have quite a long log, even if I do logcat '*:E'. Is this useful?

26

The easiest fix is to restart a phone.

27

That does not help, unfortunately. The first time it was fixed by a complete reinstall, as in, wiping all data, apps and AAS and reinstalling. The second time by the 5.0.0.73 update, which apparently does something with AAS.

I am quite unhappy that I was never able to find the real reason/cause so that it can actually be fixed.

1 Like
28

Hoping that this helps:
I also got an AAS crashing loop on a JC2 (SFOS 5.0.0.72)

In my case, I think that it’s related to Android’s touch input somehow.
If I start an app and just leave it there, it keeps working indefinitely without crashing.
The crash can be reproducibly caused by tapping on the screen repeatedly, or by “long-tapping” for more than ~2s (any of the two causes it).
After the crash, AAS goes into a start-stop loop until I go to the settings page and press on the Stop button right after it starts. After that I can start it again, and it works (unless I make it crash in the same way).

How it started:

I think it was caused by me changing something related to the screen in the Android settings (the settings app within Android), likely in the accessibility settings, but I don’t remember exactly what. The app crashed after I did, and I wasn’t able to go back to check.
After reading this thread, I tried cleaning the cache and data from Android’s Settings app to try to undo whatever I had changed, but it did not make the crashes stop.

Additional details:

  • Connectivity does not seem to have an effect in this case: I observed the same with wi-fi on and off (device is usually in airplane mode)
  • Different switches in the (SFOS’s) settings page do not seem to have a clear influence either. AAS on startup is also off.
  • If I only tap on Android apps sparsely (leaving around 5s between taps), it usually does not crash, but that obviously hinders functionality
  • Tapping on the SFOS keyboard for text input within an Android app does not seem to cause crashes either
  • I get the feeling that demanding GUIs make the crash more likely to happen: scrolling on Telegram’s previous interface’s chat list caused a crash every time I tried it (not many, tbf), but on the new interface (supposedly re-written to be more efficient) and disabling every effect I could, I was able to quickly scroll without crashes
  • Demanding GUIs alone do not seem to cause the crash if they don’t overlap too much with a tap: if I tap quickly on a Youtube video on Telegram, the in-app viewer opens and sometimes the interface slows down, but as long as I don’t tap again, the video ends up playing normally without a crash (often playing better than on the default browser).
    Tapping to close the video caused crashes sometimes, especially when the video was re-loading (after finishing). If I let it auto-restart and play for a bit before closing it with the “back” button, it does not seem to crash

It seems that there are a few different crashes which cause these AAS restart loops. If anyone’s case matches what I observed, feel free to comment here and add your own experience. I’ll also be happy if this helps make anyone’s AAS (a bit) more usable.
To avoid mixing different crashes together, we can maybe call the one in this comment “tap-related AAS crash (loop)” for the time being.
(Edit: formatting)

29

@paulvt I just noticed that this is not the main thread, and my case does not match yours (since in your case you cannot even start apps, so it’s not touch-related). Should I delete this and re-post it there?

30

Mods can also move your posts into new thread.

31

It is indeed different from what I have have. My AAS starts, is alive for 3 seconds and dies.
I cannot seem to figure out what triggers the crash.

1 Like
32

The last error is:

--------- beginning of crash
03-02 08:25:09.719   217   320 E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: NetworkWatchlistService
03-02 08:25:09.719   217   320 E AndroidRuntime: java.lang.OutOfMemoryError: Failed to allocate a 48 byte allocation with 5184 free bytes and 5184B until OOM, target footprint 268435456, growth limit 268435456; giving up on allocation because <1% of heap free after GC.
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.org.conscrypt.OpenSSLMessageDigestJDK.engineDigest(OpenSSLMessageDigestJDK.java:148)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at java.security.MessageDigest$Delegate.engineDigest(MessageDigest.java:689)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at java.security.MessageDigest.digest(MessageDigest.java:425)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.server.net.watchlist.DigestUtils.getSha256Hash(DigestUtils.java:52)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.server.net.watchlist.DigestUtils.getSha256Hash(DigestUtils.java:38)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.server.net.watchlist.WatchlistLoggingHandler.lambda$getDigestFromUid$0$com-android-server-net-watchlist-WatchlistLoggingHandler(WatchlistLoggingHandler.java:349)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.server.net.watchlist.WatchlistLoggingHandler$$ExternalSyntheticLambda0.apply(Unknown Source:6)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1742)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.server.net.watchlist.WatchlistLoggingHandler.getDigestFromUid(WatchlistLoggingHandler.java:329)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.server.net.watchlist.WatchlistLoggingHandler.getAllDigestsForReport(WatchlistLoggingHandler.java:309)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.server.net.watchlist.WatchlistLoggingHandler.tryAggregateRecords(WatchlistLoggingHandler.java:277)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.server.net.watchlist.WatchlistLoggingHandler.handleMessage(WatchlistLoggingHandler.java:120)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:106)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at android.os.Looper.loopOnce(Looper.java:201)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:288)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at android.os.HandlerThread.run(HandlerThread.java:67)
03-02 08:25:09.719   217   320 E AndroidRuntime: 	at com.android.server.ServiceThread.run(ServiceThread.java:44)
1 Like
33

@filip.k Feel free to do so if that’s due in this situation. I’m not very familiar with how these things work in the forum, so I’ll trust your criterion.
The main limitation is that I’ll likely need to focus on mwc stuff from tomorrow to Thursday, so I may have to stay away from other threads

1 Like
34

Is there some place to check or even adjust the VM heap/memory size limits for AAS?

35

I’d start in /opt/appsupport/etc and /etc/appsupport.conf.d/.

Tweaks should go in the latter.

36

Thanks. I think you meant /opt/appsupport/etc? I already browsed through there but could not find anything related to memory limits, unfortunately.

1 Like
37

I guess you’ll need to read LXC documentation. I’d be very surprised if that isn’t configurable.

38

I will have a look. But it is the Android VM that mentions its VM size limit and complains that it goes over (probably when starting up all “start on boot” applications), so I’m not sure if it is LXC related?

39

SFOS’ app support is based on LXC. You will see once you start digging into the shell scripts and config options, and shell scripts that write config options.

40

I am aware! I meant the issue seems more in the area of the Android JVM.