Crash: android.os.TransactionTooLargeException #9685

loremattei · 2019-04-23T09:56:38Z

This one started in 11.8 and has been becoming more prominent in 12.0 and 12.1.
It's currently the most common crash in Fabric.

Unluckily, the crash logs doesn't say much about where it occurs, but Fabric suggests that it is often seen when transferring bitmaps between Activities, or when saving a large amount of state between Activity configuration changes.

We had other occurrences of it in the past: #5456.

Also, this thread facebook/react-native#19458 suggests that it may be related to React-Native. The trend we see in Fabric (started in 11.8, growth a bit in 11.9, growth a lot in 12.0 and 12.1) seems to be compatible with mobile Gutenberg deployment in the app.

android.os.BinderProxy.transactNative (BinderProxy.java)
android.os.Looper.loop (Looper.java:176)
android.app.ActivityThread.main (ActivityThread.java:6635)
java.lang.reflect.Method.invoke (Method.java)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:823)

5c93a36df8b88c2963f28894-fabric

The text was updated successfully, but these errors were encountered:

designsimply · 2019-04-23T18:09:01Z

30-day impact: ~40 times a day
Latest version affected: 12.2
_{5c93a36df8b88c2963f28894-fabric-android}

The trend we see in Fabric (started in 11.8, growth a bit in 11.9, growth a lot in 12.0 and 12.1) seems to be compatible with mobile Gutenberg deployment in the app.

cc @koke to get input on priority since it was mentioned as possibly related to Gutenberg Mobile and also because it is currently the most common crash.

koke · 2019-04-29T13:33:27Z

I'm not super familiar with Android, but I looked at the logs for a bunch of crashes and the pattern I'm seeing is that it happens when the application is closing and it's trying to save its state. For instance:

11:18:30:394 (UTC) | D/CrashlyticsCore w/WordPress-UTILS: No valid URLs passed to URLFilteredWebViewClient! HTTP Links in the page are NOT disabled, and ALL URLs could be loaded by the user!!
11:18:30:689 (UTC) | D/CrashlyticsCore d/WordPress-NOTIFS: notifications pager > adapter saveState
11:27:17:484 (UTC) | D/CrashlyticsCore i/WordPress-UTILS: App goes to background
11:27:17:501 (UTC) | D/CrashlyticsCore i/WordPress-STATS: 🔵 Tracked: application_closed, Properties: {"last_visible_screen":"Notifications","time_in_app":569}

designsimply · 2019-05-09T23:07:43Z

30-day impact: ~41 per day
Users affected: 961
Last seen in: 12.3 (Sentry issue: WORDPRESS-ANDROID-23)

^{(5c93a36df8b88c2963f28894-fabric-android)}

Note: in 12.3 we switched to using Sentry and this issue is showing up there but is far more common in older versions of Android so far (or we do not have enough data for 12.3 yet to compare).

planarvoid · 2019-05-14T09:01:12Z

This crash is indeed related to #5456 and it's happening because we're saving too much stuff into the savedInstanceState all over the place. I've found out the following:

TransactionTooLargeException occurs because the Parcel objects stored in Binder transaction buffer exceeds the limited size of 1Mb. The Binder transaction buffer is shared by all transactions in progress for the process. Consequently this exception can be thrown when there are many transactions in progress even when most of the individual transactions are of moderate size.

I think this means that any place in the app could cause this issue (or any place where we store a lot of stuff into the savedInstanceState). The proper solution would be to cache the data and only save IDs into savedInstanceState (and I see that's been done in the NotificationsDetailActivity) and use ViewModels to keep the visible state.

designsimply · 2019-05-17T20:01:19Z

A mobile request for help which came in over Apr and May may be a candidate for this crash and the user reported the following example steps to reproduce the issue they are facing:

Create a new post using the Aztec editor in the app on an Android Tablet.
Add 3000+ words.
Add at least 6 YouTube video embeds.
Add 45 to 85 images throughout the post.
Try landscape and portrait modes.

I think the large number of images are the culprit in their case.

_{(internal references: p4a5px-2om-p2/#comment-9755 and 1953510-zen)}

designsimply · 2019-06-05T22:29:34Z

Copying over steps to reproduce from a similar crash report at #5456 (comment).

Steps to reproduce:

On the web write a huge post. I used plain text only (460kb and 1mb )
On your device enable "Don't keep activities".
Open the post in Visual Editor.
Press Home button to leave application.
Notice crash.

byencho · 2019-06-06T14:05:43Z

As mentioned in #5456 (comment) , if you can identify specific places where you put too much stuff in a savedInstanceState Bundle, you can use https://github.com/livefront/bridge as a (potentially temporary) workaround to avoid the crash. This works for Activities, Fragments, Views, ViewModels, etc. This library takes your Bundle data and manually saves it so that the OS doesn't need to push that data across processes to save it itself (which is when the TransactionTooLargeException will get triggered).

designsimply · 2019-07-11T21:06:40Z

30-day impact: ~37 per day
Users affected: 885 in the last 30d
First seen in: 11.8
Last seen in: 12.7.1 (latest major release at the time of this report)

^{https://sentry.io/share/issue/ed6aca84b5d74e40b016c9472defe828/}

antonis · 2023-10-26T17:43:24Z

Reopening the issue since there are still occurrences in the latest release 23.4 (ref https://a8c.sentry.io/share/issue/ed6aca84b5d74e40b016c9472defe828/)

Pasting the stack trace:

android.os.TransactionTooLargeException: data parcel size 535144 bytes
    at android.os.BinderProxy.transactNative(BinderProxy.java)
    at android.os.BinderProxy.transact(BinderProxy.java:662)
    at android.app.IActivityClientController$Stub$Proxy.activityStopped(IActivityClientController.java:1309)
    at android.app.ActivityClient.activityStopped(ActivityClient.java:85)
    at android.app.servertransaction.PendingTransactionActions$StopInfo.run(PendingTransactionActions.java:143)
    at android.os.Handler.handleCallback(Handler.java:942)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loopOnce(Looper.java:226)
    at android.os.Looper.loop(Looper.java:313)
    at android.app.ActivityThread.main(ActivityThread.java:8762)
    at java.lang.reflect.Method.invoke(Method.java)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:604)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)
java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 535144 bytes
    at android.app.ActivityClient.activityStopped(ActivityClient.java:88)
    at android.app.servertransaction.PendingTransactionActions$StopInfo.run(PendingTransactionActions.java:143)
    at android.os.Handler.handleCallback(Handler.java:942)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loopOnce(Looper.java:226)
    at android.os.Looper.loop(Looper.java:313)
    at android.app.ActivityThread.main(ActivityThread.java:8762)
    at java.lang.reflect.Method.invoke(Method.java)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:604)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

fluiddot · 2023-11-10T16:54:19Z

Sentry events analysis

I couldn't find any pattern after reviewing different Sentry events and sessions. However, I did notice that all of them are Atomic sites. This might be a clue although I couldn't reproduce the crash when testing an Atomic site.

As shared internally by @antonis (pcdRpT-4n3-p2#comment-7328), this crash has experienced a dramatic increase in version 23.5. But none of the changes either introduced in the app (reference) and the editor (reference) seem to be related to this.

Debugging stack trace

The only area of the app that can be associated with the crash is the editor, as the stack trace points to the function EditPostActivity.saveInstanceState. I've analyzed the data saved in the state using toolargetool in order to identify the culprit of this crash. Here are the results:

Steps:

Create a post.
Add different blocks.
Add an Image block.
In the "Choose image" bottom sheet, select "Choose from device".
Dismiss the media picker and repeat step 4.

For the above scenario, I found that the saved state can easily reach between 200 - 300 KB. I identified two main actors for the unexpected size:

Theme data

Theme data is included as arguments for the two Gutenberg fragments** (GutenbergEditorFragment and GutenbergContainerFragment). As part of this data, we have two properties (rawFeatures and rawStyles) that hold a long JSON string. Per the tests I performed using different themes, this adds around 64 KB per fragment, i.e. 128 KB in total.

I tried to increase the data size by customizing a theme but this didn't end up incurring an extra size. I thought this might be a theme-specific issue. However, after testing the same themes used by users who experienced the issue, none of them have led to the crash.

NOTE: The key used to hold the data in the bundle is param_gutenberg_props_builder.editorTheme.

State of views used within the editor

Depending on the content of the post, I noticed that the instance state can be incremented.

+41 KB for an empty image and one paragraph.
+81 KB for an empty image and 15 paragraphs.
+117 KB for an empty image and 30 paragraphs.

This data is in the state of GutenbergEditorFragment with the key android:view_state in the form of an array. In the case of having 15 paragraphs, I saw the array can be really long with over 800 items. Some of them are generic and I couldn't identify the origin, but others referenced Aztec.

I'm unaware if we really need to keep the state of Aztec views, so might be interesting to explore how to remove this in the spirit to reduce the state size.

`TransactionTooLargeException`

Oddly, after testing different scenarios, I couldn't manage to make the instance state big enough to raise this exception. I'm wondering if the previous state upon entering the editor might be implicated. Based on the error logs, several of the crashes happen when reaching 500 KB, so taking into account that the editor easily takes 250 KB, the other half might be coming from other views/fragments. In any case, I haven't confirmed this hypothesis and we'd need to investigate further.

Version 24.5 vs version 24.4

I performed the same analysis on both versions 24.4 and 24.5 and got the same results.

Next Steps

Test Atomic sites thoroughly and perform stress tests in the editor. The idea is to find a consistent way to reproduce the crash.
Explore options to remove theme data from Gutenberg fragments.
Investigate further views under the editor that are saving their state (e.g. Aztec).

antonis · 2023-11-10T17:05:36Z

Thank you for the detailed investigation and report @fluiddot 🙇

after testing different scenarios, I couldn't manage to make the instance state big enough to raise this exception.

Same. I wasn't able to reproduce a crash.

I'm unaware if we really need to keep the state of Aztec views, so might be interesting to explore how to remove this in the spirit to reduce the state size.

Good idea 👍

Since we cannot predict the size of the data on each site I think our best bet would be to replace the current mechanism that passes the data in the Bundle with an implementation that saves everything (or at least the large data) in the database.

fluiddot · 2023-11-10T17:13:00Z

Since we cannot predict the size of the data on each site I think our best bet would be to replace the current mechanism that passes the data in the Bundle with an implementation that saves everything (or at least the large data) in the database.

I totally agree. A comment in this issue (#9685 (comment)) also pointed out a similar solution by using the library https://github.com/livefront/bridge.

antonis · 2024-01-30T20:42:33Z

The TransactionTooLargeException also occurs in WPWebViewActivity

Reopening since this is not covered yet

antonis · 2024-02-02T17:55:06Z

The TransactionTooLargeException also occurs in WPWebViewActivity

I haven't managed to reproduce this issue on my device but there are reports (Chromium issue) that the WebView.saveState (used in the parent activity WebViewActivity) might be the root of the crash.
Note that the behaviour of this method has changed since this code was introduced 9 years ago and the method no longer stores the display data for the WebView which might make it obsolete.
Similar to this SO report I experimented with removing this call (see the patch below) and didn't notice any difference on the WebView behaviour in my (not so extensive) tests.

diff --git a/WordPress/src/main/java/org/wordpress/android/ui/WebViewActivity.java b/WordPress/src/main/java/org/wordpress/android/ui/WebViewActivity.java
index 8770f417b37..2cd5bb5fc55 100644
--- a/WordPress/src/main/java/org/wordpress/android/ui/WebViewActivity.java
+++ b/WordPress/src/main/java/org/wordpress/android/ui/WebViewActivity.java
@@ -80,24 +80,6 @@ public abstract class WebViewActivity extends LocaleAwareActivity {
         }
     }
 
-    /*
-     * save the webView state with the bundle so it can be restored
-     */
-    @Override
-    protected void onSaveInstanceState(Bundle outState) {
-        mWebView.saveState(outState);
-        super.onSaveInstanceState(outState);
-    }
-
-    /*
-     * restore the webView state saved above
-     */
-    @Override
-    protected void onRestoreInstanceState(Bundle savedInstanceState) {
-        super.onRestoreInstanceState(savedInstanceState);
-        mWebView.restoreState(savedInstanceState);
-    }
-
     @Override
     protected void onPause() {
         super.onPause();

A fix like the above would require extensive testing since it would affect the SSLCertsViewActivity, the WPWebViewActivity which is used across the app and also extended by:DomainRegistrationCheckoutWebViewActivity, DomainManagementDetailsActivity, ThemeWebActivity, SupportWebViewActivity and JetpackConnectionWebViewActivity.

Considering the above and that I haven't managed to reproduce the crash to validate this as a fix I haven't proceeded with a PR with this approach yet.

Another (maybe safer) hacky alternative would be to remove the WEBVIEW_CHROMIUM_STATE from the saved Bundle when it exceeds a certain threshold. Something like this is also used in the Chromium source code.

sentry-io · 2024-02-07T11:54:46Z

Sentry issue: JETPACK-ANDROID-7Y4

sentry-io · 2024-02-07T12:19:11Z

Sentry issue: JETPACK-ANDROID-8HV

antonis · 2024-02-12T16:47:34Z

Marking as resolved in 24.2 with #19747, #20046 and #20139. I'll keep an eye for any regressions in Sentry

sentry-io · 2024-02-12T16:54:17Z

Sentry issue: WORDPRESS-ANDROID-2V8H

antonis · 2024-02-23T09:14:50Z

Marking as resolved in 24.2 with #19747, #20046 and #20139. I'll keep an eye for any regressions in Sentry

With 24.2 fully rolled out 6 crashes by 3 users were recorder this week all of them in the WordPress app editor on low end devices. From the logs the following might indicate the usage of Aztec 🤔

e/WordPress-EDITOR: HTML content of Aztec Editor before the crash:
editor_opened, Properties: {"blog_id":...,"post_id":..,"has_gutenberg_blocks":false,"site_type":"blog","post_type":"post","post_format":"standard","is_jetpack":false,"editor_has_hw_disabled":"0"}

I'll keep monitoring the issue and iterate with additional fixes if needed.

sentry-io · 2024-03-14T11:30:44Z

Sentry Issue: WORDPRESS-ANDROID-2QCB

sentry-io · 2024-03-14T11:31:49Z

Sentry Issue: JETPACK-ANDROID-E9W

sentry-io · 2024-03-14T11:42:56Z

Sentry Issue: WORDPRESS-ANDROID-2TD8

antonis · 2024-03-14T11:44:32Z

I've linked a few more occurrences of TransactionTooLargeException. In the past 30d and in the latest public versions of the app (24.2 and 24.3.1 that include the fixes #9685 (comment)) 12 users encountered 21 crashes in total.

sentry-io · 2024-03-28T08:44:41Z

Sentry Issue: JETPACK-ANDROID-MKP

dangermattic · 2024-03-28T08:47:37Z

Thanks for reporting! 👍

antonis · 2024-03-28T08:49:58Z

Given that the occurrences of TransactionTooLargeException related crashes after 24.2 is low I lowered the priority to medium. I'll keep monitoring and fix issues as needed.

sentry-io · 2024-03-28T13:25:40Z

Sentry Issue: WORDPRESS-ANDROID-2W93

sentry-io · 2024-04-04T14:09:21Z

Sentry Issue: JETPACK-ANDROID-P5N

antonis · 2024-04-12T13:55:47Z

I'm marking this as resolved as there are no occurrences in the latest version. I'll keep an eye for regressions.

antonis · 2024-05-30T11:42:16Z

Opened a separate issue for the MediaPreviewActivity related crashes #20913

designsimply added [Type] Crash gutenberg-mobile labels Apr 23, 2019

designsimply added General and removed gutenberg-mobile labels May 17, 2019

designsimply added the Mobile Request label Jun 5, 2019

designsimply mentioned this issue Jun 5, 2019

Crash: TransactionTooLargeException #5456

Closed

shiki self-assigned this Jul 16, 2019

This was referenced Jul 16, 2019

Groundskeeping (Android) Master Issue: Jul 15 to Jul 19, 2019 #10217

Closed

Use local post ID in HistoryList to fix TransactionTooLargeException #10240

Merged

malinajirka closed this as completed in #10240 Jul 22, 2019

antonis mentioned this issue Apr 8, 2021

Page Layout Picker crashes when resuming from the background #14421

Closed

antonis reopened this Oct 26, 2023

antonis unassigned shiki Oct 26, 2023

antonis reopened this Jan 30, 2024

antonis added the [Pri] High label Feb 7, 2024

antonis mentioned this issue Feb 7, 2024

Prevents TransactionTooLargeException error in WebViewActivity #20139

Merged

13 tasks

antonis closed this as completed Feb 12, 2024

antonis reopened this Feb 23, 2024

antonis added [Pri] Medium and removed [Pri] High labels Mar 28, 2024

antonis closed this as completed Apr 12, 2024

antonis mentioned this issue May 30, 2024

TransactionTooLargeException in MediaPreviewActivity #20913

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Crash: android.os.TransactionTooLargeException #9685

Crash: android.os.TransactionTooLargeException #9685

loremattei commented Apr 23, 2019

designsimply commented Apr 23, 2019

koke commented Apr 29, 2019 •

edited

Loading

designsimply commented May 9, 2019 •

edited

Loading

planarvoid commented May 14, 2019

designsimply commented May 17, 2019

designsimply commented Jun 5, 2019

byencho commented Jun 6, 2019

designsimply commented Jul 11, 2019

antonis commented Oct 26, 2023 •

edited

Loading

fluiddot commented Nov 10, 2023

antonis commented Nov 10, 2023

fluiddot commented Nov 10, 2023

antonis commented Jan 30, 2024

antonis commented Feb 2, 2024 •

edited

Loading

sentry-io bot commented Feb 7, 2024

sentry-io bot commented Feb 7, 2024

antonis commented Feb 12, 2024

sentry-io bot commented Feb 12, 2024

antonis commented Feb 23, 2024

sentry-io bot commented Mar 14, 2024

sentry-io bot commented Mar 14, 2024

sentry-io bot commented Mar 14, 2024

antonis commented Mar 14, 2024

sentry-io bot commented Mar 28, 2024

dangermattic commented Mar 28, 2024

antonis commented Mar 28, 2024

sentry-io bot commented Mar 28, 2024

sentry-io bot commented Apr 4, 2024

antonis commented Apr 12, 2024

antonis commented May 30, 2024

Crash: android.os.TransactionTooLargeException #9685

Crash: android.os.TransactionTooLargeException #9685

Comments

loremattei commented Apr 23, 2019

designsimply commented Apr 23, 2019

koke commented Apr 29, 2019 • edited Loading

designsimply commented May 9, 2019 • edited Loading

planarvoid commented May 14, 2019

designsimply commented May 17, 2019

designsimply commented Jun 5, 2019

byencho commented Jun 6, 2019

designsimply commented Jul 11, 2019

antonis commented Oct 26, 2023 • edited Loading

fluiddot commented Nov 10, 2023

Sentry events analysis

Debugging stack trace

Theme data

State of views used within the editor

TransactionTooLargeException

Version 24.5 vs version 24.4

Next Steps

antonis commented Nov 10, 2023

fluiddot commented Nov 10, 2023

antonis commented Jan 30, 2024

antonis commented Feb 2, 2024 • edited Loading

sentry-io bot commented Feb 7, 2024

sentry-io bot commented Feb 7, 2024

antonis commented Feb 12, 2024

sentry-io bot commented Feb 12, 2024

antonis commented Feb 23, 2024

sentry-io bot commented Mar 14, 2024

sentry-io bot commented Mar 14, 2024

sentry-io bot commented Mar 14, 2024

antonis commented Mar 14, 2024

sentry-io bot commented Mar 28, 2024

dangermattic commented Mar 28, 2024

antonis commented Mar 28, 2024

sentry-io bot commented Mar 28, 2024

sentry-io bot commented Apr 4, 2024

antonis commented Apr 12, 2024

antonis commented May 30, 2024

koke commented Apr 29, 2019 •

edited

Loading

designsimply commented May 9, 2019 •

edited

Loading

antonis commented Oct 26, 2023 •

edited

Loading

`TransactionTooLargeException`

antonis commented Feb 2, 2024 •

edited

Loading