Open fluiddot opened 1 year ago
I spent time reviewing the history and logs for this crash. Capturing a few notes for posterity.
Timeout reached before response from requestGetHtml
, EditPostRepository: Transaction is writing on a locked thread
.After spending more time debugging this, I am still unable to reproduce the error.
For next steps, I plan to implement a few more block editor analytic events to see if they help uncover any specific actions that correlate with this error. In the meantime, I will keep myself assigned to this issue as the DRI, but I do not plan to debug it further at this time.
Sentry issue: WORDPRESS-IOS-452F
Sentry issue: JETPACK-IOS-14MW
From further testing, my belief is that this crash and others (https://github.com/wordpress-mobile/gutenberg-mobile/issues/6127, https://github.com/wordpress-mobile/gutenberg-mobile/issues/6128, https://github.com/wordpress-mobile/gutenberg-mobile/issues/6203) may relate to performance issues. Specifically, posts with a good number of images often slow or hangs when attempting to persist the post content via the Update or Save buttons.
Before or during this period of a hanging app, one can queue up several actions by tapping various UI element — moving blocks, opening block settings, inserting blocks, etc. My belief is that these queued actions could ultimately be executed against incorrect or nonexistent blocks once the app resumes and the various logic for each interaction are finally executed.
I was able to twice reproduce a crash with a similar stack trace to https://github.com/wordpress-mobile/gutenberg-mobile/issues/6128 with the following:
Once the persisting the post updates finished, the app attempted to open the block settings and threw the crash referenced in https://github.com/wordpress-mobile/gutenberg-mobile/issues/6128. Unfortunately, while the stack trace resembles the crash, it does not include the details required (line numbers) for symbolicating the stack trace.
An update regarding the stack trace: I was able to symbolicate the stack trace after discovering the additional details are available in Xcode when clicking the "hamburger menu" icon next to the crash (captured in an image below).
The symbolicated stack trace is attached below as well. It appears to point to the fact that getBlock
returns null
(which is possible) and we attempt to access a name
attribute on the null
block.
To be clear, this finding is not a resolution to this issue. It relates more to https://github.com/wordpress-mobile/gutenberg-mobile/issues/6128. However, all of these issues (https://github.com/wordpress-mobile/gutenberg-mobile/issues/6127, https://github.com/wordpress-mobile/gutenberg-mobile/issues/6128, https://github.com/wordpress-mobile/gutenberg-mobile/issues/6203, https://github.com/wordpress-mobile/gutenberg-mobile/issues/6359) still seem related to poor editor performance from my perspective. My thought is that a race condition exists that is exasperated by a hanging editor with low performance.
Random thought: I wonder if upgrading to React Native >=0.72
will provide additional, helpful details for cryptic errors like this one.
Sentry issue: JETPACK-ANDROID-HRK
Extracted from the breadcrumbs of JETPACK-ANDROID-HRK, I noticed the following native error:
e/WordPress-EDITOR: Illegal selection index for text with length 12, selectionStart: 13, selectionEnd: 13, with UnknownHtmlSpan tags: []
e/WordPress-EDITOR: StackTrace: org.wordpress.mobile.ReactNativeAztec.IllegalSelectionIndexException: Illegal selection index for text with length 12, selectionStart: 13, selectionEnd: 13, with UnknownHtmlSpan tags: []
at org.wordpress.mobile.ReactNativeAztec.ReactAztecManager.updateSelectionIfNeeded(ReactAztecManager.java:257)
at org.wordpress.mobile.ReactNativeAztec.ReactAztecManager.setTextfromJS(ReactAztecManager.java:239)
at org.wordpress.mobile.ReactNativeAztec.ReactAztecManager.setText(ReactAztecManager.java:220)
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:93)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:86)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:142)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:915)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1026)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1086)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1090)
at android.view.Choreographer.doCallbacks(Choreographer.java:893)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1078)
at android.os.Handler.handleCallback(Handler.java:907)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:216)
at android.app.ActivityThread.main(ActivityThread.java:7625)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:524)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:987)
I wonder if this might be a clue to narrow down the culprit of the crash.
Sentry issue: JETPACK-ANDROID-J1Z
Sentry Issue: WORDPRESS-ANDROID-2VAA
Sentry Issue: JETPACK-ANDROID-JM6
Removing my assignment as I do not intend to work on this for the foreseeable future.
Our latest plan for addressing this crash was seeing if the React Native 0.73 upgrade provided additional clues for the origin of this crash.
Sentry Issue: JETPACK-ANDROID-HRK
Symbolicated stack trace:
Raw stack trace ⤵️
``` value@1:436892 value@1:436464 onResponderRelease@1:435281 c@1:359373 m@1:359430 v@1:359462 w@1:359594 Le@1:363833 $@1:361102 anonymous@1:364185 Ce@1:421849 Ne@1:363753 Me@1:364026 receiveTouches@1:416736 value@1:166857 anonymous@1:165357 value@1:166303 value@1:165315 ```