Project

General

Profile

Actions

Bug #971

closed

android.os.TransactionTooLargeException with lots of tabs

Added by Air Yes over 1 year ago. Updated 5 months ago.

Status:
Closed
Priority:
Next Release
Start date:
03/07/2023
Due date:
% Done:

0%

Estimated time:

Description

Another routine crash. Not funny though all those tabs get lost and ots a lot of time to get that data back on screen...


Files

PB Crash no reason mar 6.23.txt (1.46 KB) PB Crash no reason mar 6.23.txt Air Yes, 03/07/2023 12:36 AM
crash.log.txt (209 KB) crash.log.txt ask low, 12/18/2023 12:29 PM
Actions #1

Updated by Soren Stoutner over 1 year ago

  • Assignee set to Soren Stoutner

How many tabs did you have open?

Actions #2

Updated by Soren Stoutner over 1 year ago

  • Subject changed from Crash ctash crash to android.os.TransactionTooLargeException with lots of tabs
Actions #3

Updated by Soren Stoutner over 1 year ago

  • Status changed from New to Feedback
  • Priority changed from 3.x to Next Release
Actions #4

Updated by Soren Stoutner about 1 year ago

Can you confirm how many tabs you had opened when this crash occurred? I do not know if the number of tabs is related to the problem, but knowing how many you had opened would be helpful in ruling that out or indicating it is worth pursuing.

Actions #5

Updated by Soren Stoutner about 1 year ago

I did a bit of testing myself. Somewhere around thirty tabs I was able to get the system to generate this error if the app was restarted in the background.

Actions #6

Updated by Soren Stoutner about 1 year ago

  • Status changed from Feedback to Closed

There is a blog post about why Android likes to close your tabs if too many are open at https://www.stoutner.com/if-you-have-too-many-tabs-sometimes-they-disappear/.

Actions #7

Updated by ask low 8 months ago

Do you think is there any workaround for this ? I'm literally a superuser of my device (might've chance to revive this through root somehow ?)

I typically don't wanna hear the word "not possible" when the whole ecosystem is open source...

Actions #8

Updated by Soren Stoutner 8 months ago

I would imagine you could change this ridiculously low memory limit (1 MB) if you compiled Android from scratch. It would be a nice feature to add to a custom ROM.

Actions #9

Updated by ask low 8 months ago

Strange. It's very bizzare how android's memory management is pathetic from the groundup.

Actions #10

Updated by Soren Stoutner 8 months ago

In my opinion it is the single worst thing about Android. It was designed back in the day when the original G1 only had 192 MB of RAM.

https://www.gsmarena.com/t_mobile_g1-2533.php

But, even though phones now have plenty of RAM, they don't change the design because killing apps in the background is the only way they can maintain their battery life. Most apps are so poorly programmed and spend so much time tracking their users that if the OS didn't kill them in the background the battery life on most phones would be measured in minutes.

Actions #11

Updated by ask low 8 months ago

I heard from an iOS app dev somewhere on Reddit that iOS basically frees it's memory based on the timing of the cached memory. Like each app's cache is indexed in such a way that iOS purges only the oldest memory of all open app caches one by one, when the new cache is generated. This is the main reason how one can access the last app in the recents all the way without reloading/recaching !

If you take a browser as an example, that would mean that the only cache freed is that of the oldest open tab. Apple's able to achieve these fine granularity just caz their development policy is very closed & strict.

I hope you'll learn xcode or shift in the future and port privacy Browser there :D (I'm joking, don't)

Actions #12

Updated by Soren Stoutner 8 months ago

If all the OS did was prune cache it would never cause any problems. Android goes way beyond that, but I have not idea how iOS handles things.

Actions #13

Updated by ask low 7 months ago

It's very strange that other browser (kiwi in my case) didn't even crash with 20 tabs, was even able to switch between them from 1st to last tab without a single reload, also the browser didn't crash at all. And moreover, 600 mB of memory was still available/free.

This is not at all the case for PB. I think the core issue is the lack of webview control. Not the memory scheduler of Android.

Actions #14

Updated by Soren Stoutner 7 months ago

Most browsers solve this problem by writing the browser tabs to storage when they are killed in the background by the OS. Privacy Browser specificially doesn't do this because, even if they are deleted later, there is no guarantee they can't be recovered by Cellebrite or some other malicious program that gets access to the device. To realize how common it is to recover items from flash storage that have been deleted, reflect on the number of court cases where someone deleted a text or a photo or something else from their phone only to have it be successfully recovered.

So, for privacy and security reasons, Privacy Browser will never automatically write the browsing history or open tabs or anything else to flash storage. This is one of the things that differentiates Privacy Browser from other browsers on the market. I have written more about this at:

https://www.stoutner.com/privacy-browser-android/core-privacy-principles/

Actions #15

Updated by ask low 7 months ago

Yup. Disabled network, force closed the browser without closing open tabs & reopened it. It still views pages in offline mode !
EDIT : I just pointed /cache/Offline Pages directory to /dev/null. Problem Solved.

Actions #16

Updated by Soren Stoutner 7 months ago

I would recommend you read what is written in the Guide about Local Storage, particularly about Clear and Exit. Also take a look at Incognito Mode and Feature #34: WebView Cache Controls. Also note that Privacy Browser PC already disables all writing of cache information, including service workers, to storage. They are only maintained in RAM, are not shared between tabs, and are eliminated from RAM when the tab is closed. This will become the default in Privacy Browser Android in the 4.x series with #34.

Actions #17

Updated by ask low 6 months ago

Is there no other way to prevent crashes due to switching to another app ? It's being crashing a lot lately.
Although I use a custom kernel developed by an amazing guy with superior knowledge. RAM management is dependent on kernel right ?

Actions #18

Updated by Soren Stoutner 6 months ago

I would recommend practicing good internet hygiene by not maintaining a lot of open tabs. Any time you have a lot of tabs open you always run the risk that one tab will be able to steal information from another tab, despite everything your browser does to try to prevent that from happening.

Actions #19

Updated by ask low 6 months ago

It even happened on couple of tabs actually.
I think crashes are due to the improper memory utilisation something like that. It literally felt like some sort of race condition kicking in.
Even happened when I use Google search with disabled script just yesterday. Very strange though.

Actions #20

Updated by Soren Stoutner 6 months ago

That could be. Note that the size of the WebView history is also a factor. Every time you visit a new website in a WebView it stores the favorite icon in the history. All of those favorite icons then become part of the saved system state. If that exceeds the 1 MB artificial limit, then you end up with a TransactionTooLargeException.

Actions #21

Updated by ask low 6 months ago

Isn't it possible to overcome these artificial limits ? The free memory of my device just sitting doing nothing but providing random race condition like crashes to the browser.

Actions #22

Updated by Soren Stoutner 6 months ago

Yes. You could ask Google to remove the artificial limit. Or, you could also ask the people who make your ROM, which I believe is Lineage OS in your case, to do so.

Actions #23

Updated by ask low 6 months ago

It's actually AOSP GSI with phhusson's patches.
https://github.com/ponces/treble_aosp/releases

Do you think GSI could be the issue ?

Actions #24

Updated by Soren Stoutner 6 months ago

It could be, but I don't know enough to say.

There are two pieces to this problem, both of which can only be modified at the OS level.

The first piece is the artificially low 1 MB limit on the Saved Instance State bundle. Raising this would mean that all of Privacy Browser's data could fit into the Saved Instance State, even if more tabs are open or they contain more data (like history favorite icons). If the OS were to set that limit at 5 MB or 10 MB or 50 MB it would make a big difference.

The second piece has to do with when the OS decides to kill an app and store all of its data in the Saved Instance State bundle. Google is constantly tweaking their algorithm that decide when to do this, and so do other ROMs. Sometimes you can also tweak the settings of the OS to be nicer to a particular app.

https://dontkillmyapp.com/

Apps can be killed for two main reasons. The first is that something else wants to use the RAM. This happens if you have a lot of other apps open, but sometimes even one other app can request all the device's RAM. A good example of this is the camera, which needs lots of RAM for all the ML post-processing of photos that phones do nowadays.

The second reason is to extend battery life by preventing the app from using the CPU in the background. This is the reason why the Don't Kill My App link above has a lot of information about exempting particular apps from the phone's battery preserving sheriff. Privacy Browser doesn't actually attempt to use CPU in the background, but the phones don't often check that before killing apps.

Google changes all of this behavior with each major Android update, and sometimes even with monthly security patches. Individual ROMs also often modify this behavior, which is why some devices have a lot more problems with this than others.

Actions #25

Updated by ask low 6 months ago

The problem with that website you suggested, is that it's outdated with obsolete information. On A12+ you just need to disable battery optimization. Nothing else is required.

As I'm using the stock Android directly built by ponces with some patches applied. Do you think it's possible to fix this by switching to another ROM like lineage ?

Actions #26

Updated by Soren Stoutner 6 months ago

Your mileage may vary. You probably won't know without installing a ROM and testing it. If you do find something that works, please post it here or in the forums so that others can benefit.

I will tell you that, with my personal Pixel 5 running stock Android 14, I never encounter this problem in my daily browsing. Typically I have less than 5 tabs open at a time and I usually close Privacy Browser entirely between viewing sessions. (I open a lot of websites during the day on my device, which means that I probably completely shut down Privacy Browser by running Clear and Exit or closing the last tab at least fifty times per day.) I have to do artificial things like open twenty tabs and then leave them open while switching between several dozen other apps to force Android to produce this crash.

Actions #27

Updated by ask low 6 months ago

Maybe that manual clear & exit is the reason for instance state bundle to get reset. I think if I don't clear & exit, but rather open & close multiple tabs, there's a chance for some sort of pool to pile up ?

If so, there must be a way to clear it dynamically while closing the tabs. Maybe this is the race condition too.

Actions #28

Updated by Soren Stoutner 6 months ago

No. When a tab is closed it is completely destroyed with all of its contents. It doesn't "pile up" in any way.

However, if you keep a tab open and keep reusing it, then the history will pile up with a lot of favorite icons as described above. You can always check how many favorite icons a tab has stored by tapping History in the Navigation drawer.

Beyond that, I would recommend that everyone always completely close Privacy Browser between sessions as a fundamental aspect of good internet hygiene. If a malicious app or device (like Cellebrite) gains root access to your device, it can read what all the other apps have stored in RAM. But if Privacy Browser has been closed, there is nothing left to read. Hence, completely closing Privacy Browser between sessions decreases your possible exploitation envelope.

Actions #29

Updated by ask low 6 months ago

Weird workaround for me, seemed to be Incognito Mode feature in preferences lmao.
I'm on it since the last 6 hours. Tried opening like 20 tabs rigorously & haven't experienced a crash !
Only downside I've felt is the lack of tab history & inability to circle around old pages. It's a bit limiting but let's see how it pans out.

Actions #30

Updated by Soren Stoutner 6 months ago

One of the advantages of Incognito Mode is that there is no history, which means there are no saved historical favorite icons.

For example, if you have 5 tabs and each has a history 5 levels deep, that is 25 favorite icons. If you have 20 tabs open with no tab history that is only 20 favorite icons.

There are, of course, many other aspects of a tab that takes up space in the Saved Instance State bundle. But icons, by their very nature, add up fast.

Actions #31

Updated by ask low 6 months ago

Is it possible to introduce a feature that disables favicon storage ?

Actions #32

Updated by Soren Stoutner 6 months ago

There is one. It is called Incognito Mode.

Otherwise, no. WebView stores favorite icons for all items in its history and there is no way to prevent it from doing so.

Actions #33

Updated by ask low 6 months ago

I mean, the icons are literally media files made of ico, png or svg (which are very huge sized). Why are they even be deserved to be stored in our limited Saved Instance State bundle ?
Will the feature be possible on 4x privacy webview ?

Actions #34

Updated by Soren Stoutner 6 months ago

It would be possible in Privacy WebView, but I don't know if I would implement it.

Like I have said several times on this page, closing Privacy Browser frequently is good internet hygiene. To me, it doesn't feel like a problem that needs fixing.

Actions #35

Updated by ask low 6 months ago

Just crashed on only one tab (amazon) while switching to my notes app. Caused when I scrolled deep into the amazon search.
I'm not sure that limiting our browsing to be of 1MB SISB considered is a workaround. Also, it doesn't come under browsing hygiene caz it's also happening when we're browsing for too long on some site session (which makes it unusuable tbh).

This issue seems to be too serious for me.

Actions #36

Updated by Soren Stoutner 6 months ago

I doubt that crash was caused by this problem. If you look in the logcat you can see what is actually causing the crash. For example, it might be Bug #1106: New intents sometimes aren't loaded on restart on Android 14 (WebView crash), which is a bug in WebView that we just have to wait for them to fix upstream.

This bug is closed and there is no expectation that I will ever do anything more about it. It is the expected behavior on Android. If you would like, you can recommend to Google that they make a change in their OS.

Actions #37

Updated by ask low 6 months ago

I wish a proper SISB management could've exist. But you're saying it's not possible.
Then I believe it is also not possible to run a browser properly in memory without offloading some stuff onto the disk (which we consider insecure).

If that's insecure, then offloading cookies & local storage is also insecure. Caz all the appdata would if somehow exposed to the attackers, they'll use those cookies to spoof user very easily. Tor/incognito browsing would be the only choice then.

I think appdata would be safe unless attackers gain root access. We shouldn't be too paranoid tbh.

Actions #38

Updated by Soren Stoutner 6 months ago

One of the first things I would like to do with Privacy WebView is to disable writing of all WebView information to disk, including the cache, the service workers, and everything else. I am already able to do this with Privacy Browser PC because Qt WebEngine exposes the control to do this where Android System WebView does not.

But even after that is accomplished, it will make no difference to this issue. This issue here is that icons are part of the web history, which is part of the WebView saved state (as opposed to JavaScript or many other resources, which are not).

https://developer.android.com/reference/android/webkit/WebView#saveState(android.os.Bundle)

Not saving the favorite icons in the web history would create other problems. For instance, it would have prevented fixing Bug #1127: Site icons in tabs don't update when backtracked.

Actions #39

Updated by ask low 5 months ago

Something nice happened on alt. Now it doesn't seem to bork existing tabs while switching to other apps. Instead, the tabs reload while exist & don't clear. Did you do some sort of memory usage modification ?

Btw, I noticed #1127 bug caz favicons exist. Just saying that even if they don't exist, it would probably make no difference to me. I literally worship text browsing (which isnt possible in JS world).

And my comment on PC version:
https://redmine.stoutner.com/boards/6/topics/303?r=443#message-443

Actions #40

Updated by Soren Stoutner 5 months ago

No. Nothing in the Alt version has made any changes with regard to android.os.TransactionTooLargeException.

Actions #41

Updated by ask low 5 months ago

Memory Usage
App Consumed Memory: 19.59 MiB
App Available Memory: 8.93 MiB
App Total Memory: 28.52 MiB
App Maximum Memory: 512.00 MiB
System Consumed Memory: 3,347.77 MiB
System Available Memory: 2,251.27 MiB
System Total Memory: 5,599.05 MiB

Btw, I'm trying to understand the memory availability.
The more tabs I use, consumed memory increases. I've noticed that closing the tabs doesn't release that memory & keeps piling up. Eventually, when the consumed memory hits app available memory, that's where the app crashes.

Actions #42

Updated by Soren Stoutner 5 months ago

The answer to your question has to with Java and Kotlin garbage collection. You can find a lot of information about the topic online.

ask low wrote in #note-41:

Eventually, when the consumed memory hits app available memory, that's where the app crashes.

I don't think that is correct. If it is correct, it has nothing to do with this android.os.TransactionTooLargeException and you should submit a separate bug report about that issue with a logcat showing the error message associate with that crash.

Actions #43

Updated by ask low 5 months ago

Ok. Haven't reproduced this so can't speculate anyways.
Btw, I peeked into Dev options > Running Services, & looked like the browser is always a cached process instead of in main processes list. It acts as main process only when I'm using it. The moment I switch to another app, it quickly turns into cached process.
Is it possible to mitigate the android killing by prioritising memory by some persistent notification or something like that ? For example, Android adaptive notifications ?

Actions #44

Updated by Soren Stoutner 5 months ago

The short answer is no.

The slightly longer answer is that, even when an app is displaying a notification, that does not prevent the OS from killing the main app it in the background.

There are much longer and much more complicated versions of this answer, but the end result is that it doesn't end up helping.

Actions

Also available in: Atom PDF