Crash when opening and closing the editor: C++ Exception: NSt3__112system_errorE #20499
Comments
|
This might be related to React Native because it appears in the Stack Trace I downloaded from Sentry, e.g.: |
|
👋 @geriux, do you have any context on this crash? I saw your name in the Activity tab of the Sentry issue for this crash. I bumped into this on Snetry during my release rotation because it's the top crash in 22.0, so I created this GitHub issue to help triage. |
It looks like it is related to this issue WordPress/gutenberg#41686 and the Reanimated library. After some investigations, we couldn't find a quick solution but we had some ideas like starting using |
|
Thanks for the context, @geriux! |
|
As for next steps, should someone be assigned to this issue? I should remove the Needs Triage label once it has an assignee (see internal ref PCYsg-vRg-p2). |
|
Maybe we should add it to the Maintenance Week board? |
|
Good idea! |
guarani
changed the title
|
I assessed this as priority due to Medium severity (assuming drag & drop is a low priority feature) and Medium impact (unsure about it, but maybe 6-24% of users affected given the 101 events in last 24 hours). |
|
Do you think https://a8c.sentry.io/issues/3322079168 is a duplicate of the Sentry issue mentioned at the top of this issue, @geriux? I found them to have the same error, |
|
Thanks for the ping @guarani! Yes, I think it is. I have just added this one to the board. |
Yeah, that's the same as the other one. That's weird that it doesn't show an option to merge them 🤔 But I can see in that issue that it also happens when the editor is closed. |
|
I just realized that the two Sentry issues are in different Sentry projects (WP vs. JP) so can't be merged 🤦:
I linked both back to this GitHub issue 👍 |
😅 nice catch! Cool, thank you! |
|
@guarani I removed the "Requires Triage" label as it appears this issue was prioritized and placed on the maintenance board. Please correct me if I am wrong. Thanks! |
|
Good call about removing the "Requires Triage" label, @dcalhoun! |
|
This PR might fix this issue in |
I checked the Sentry events again now that version |
Sounds great, thanks @guarani for updating its status. |
|
Just looping back here to say that there's been no reoccurrence of this crash in the 22.8 beta so far. However, it's too early to tell if this is fixed because this crash only happened once in the 22.7 beta before happening 244 times once 22.7 was in production.
|
|
Unfortunately, there're new events for both JPiOS 22.8 and WPiOS 22.8. We need to review the new reports and look for further solutions. |
😞
The fix we incorporated for this was related to being able to identify a similar crash when upgrading React Native. It was a long shot using the same fix for the current React Native version, but we had to try. Hopefully, with the RN upgrade that includes a newer version of the Reanimated library, and the fact that we'll be also enabling Hermes, maybe the crash situation improve. The main problem with this crash is that we aren't able to reproduce it consistently. In any case, since we identified a reproduction case, we could confirm if it's reproducible in the new RN version. |
|
Thanks for a quick reply, @fluiddot!
Just to clarify, these updates were shipped together with 22.8? Or are there any further updates incoming that could potentially reduce occurrences of this crash? |
No, sorry. The changes I mentioned (i.e. the React Native upgrade) that could reduce occurrences aren't merged yet, they will be part of next version 23.0. |
Got it, thanks for the update! We'll continue monitoring the issue in upcoming releases then. |
Testing on trunk💣 Managed to reproduce the crash consistently by automating these steps: graph LR
A(Select the search bar)
A --> B(Open post)
B --> C(Dismiss post)
C --> A
After a couple of minutes I consistently get the crash matching the Sentry reports: Stack traceCode example (Edited PostListViewController.swift)Testing with updated RN versionAfter multiple runs confirming the crash is reproducible, I switched to a ✅ I wasn't able to reproduce this particular crash anymore on multiple long runs. The evidence points that when #20956 gets merged this particular issue will be resolved. Unfortunately, two times I jumped on a different crash when repeating the same steps. It didn't happen reliably for me. I informed @fluiddot about it: Unhandled JS Exception: TypeError: Cannot read property 'map' of undefined, js engine: hermes, stack: |
staskus
changed the title
|
Should be fixed by [Gutenberg] Upgrade React Native 0.71.11 on 23.0. |
|
@SiobhyB, there's a small number of crashes in 23.0 and Sentry has marked this Regressed. Does this need attention? Let me know if there's someone else I should ping. I'm on release rotation and saw your name on the PR linked in the previous comment. |
|
FWIW I followed these steps, #20499 (comment), but couldn't reproduce the crash (although since these steps weren't 100% reliable, that might be expected). |
|
Thanks @guarani! We talked about this a little on Slack today here, also: p1692690454170439-slack-C05LL2TLPKQ. Our current thoughts for next steps are as follows:
I'll go ahead to reopen this issue to reflect that it's currently under investigation and have added it to the Gutenberg Mobile Crash Focus board. 🙇♀️ |
|
👋 Looks like you were already one step ahead! Thanks, @SiobhyB 🙇 |
|
Should we update the assignee on this GitHub issue and on both the Sentry issues? That could help other release rotation folks know this is being looked into. |
Sure, I'll assign myself to the issue and take a look as soon as possible. Thanks! |
|
I've tried to reproduce the crash in version At this point, I don't have any leads to follow in order to debug the crash 😞. Regarding the next steps outlined in #20499 (comment): Investigate an active Reanimated warning in the project to see if that helps to resolve the crash.This warning is only produced when running the integration tests in Jest. It's caused because the Reanimated worklets need the native library to work, hence a warning is displayed when running a worklet in a non-native environment. Dive deeper into the current drag and drop implementation.We can revisit the implementation but we'd need first to find a consistent flow to reproduce the crash. With that, we could identify areas in the implementation that could be tweaked in order to provide a fix. We could follow the approach shared in #20499 (comment) and try to automate the steps to lead to the crash 👀. Keep monitoring the rates for this crash to see if it has at least reduced in numbers since the React Native upgrade.We probably would need to wait another week to collect the crash metrics of version
|
Another attempt to debug the crashFollowing #20647 (comment), I decided to give another try to debug the crash, but in this case, forcing the scenario where NOTE: The Jetpack iOS version I used is 23.9. I checked out this tag and built the app locally. Although not consistently, I managed to reproduce a crash with a different stack trace: The stack trace differs from the one referenced in this issue: NOTE: The stack trace referenced in #20499 (comment) no longer applies, as it was from a past version where React Native used JSC, instead of Hermes. As you can see above, the stack trace has references to what seems destroy/deallocation methods. Here are the steps I followed to produce the crash:
During testing, I managed to reproduce the original crash (Sentry event) but unfortunately, I couldn't force the same crash again and I'm not sure the steps I performed. Another factor that made me think about this hypothesis is that the Sentry breadcrumb, in most of the events, shows In this regard, I also performed another set of testing by commenting this line, as it's the one in charge of destroying the React Native environment.
I managed to reproduce a crash with the following steps:
The stack trace also differed from the original one, but again, it referenced destroy/deallocation methods. Unfortunately, this attempt although I felt it was promising, I didn't manage to narrow down the culprit. I hope that in version 24.0 and with #22265, we might see a decrease in this crash. |
|
I'm marking this resolved in 24.5.0.2, betting on the assumption that the RN upgrade in 24.5 fixed this 🤞
|
Sentry issues:
JETPACK-IOS-4AWORDPRESS-IOS-3KSCReference: Sentry search for
NSt3__112system_errorEacross both the JP and WP apps.Potential solution
The crash should be addressed with #20956. More context.
Reproduction Steps
Copied from #20499 (comment).
Footnotes
May not be necessary, but keyboard show/hide event are in numerous Sentry crash logs. ↩
Crashing occurs very infrequently. ↩
The text was updated successfully, but these errors were encountered: