Open fluiddot opened 2 years ago
π @fluiddot! Is this in progress perhaps? Asking so we move the status accordingly. Thanks!
π @fluiddot! Is this in progress perhaps? Asking so we move the status accordingly. Thanks!
@hypest Nope, this task hasn't been tackled yet. However, it would be great if we could take a look sooner than later, as it's causing some of the top 5 crashes in the WordPress-iOS app. Actually, I'm thinking to focus on this over other tasks I'm currently working on related to integration tests, wdyt?
Thanks Carlos! Yeah, makes sense to focus on this since this is a crash situation. π
I performed a deeper analysis of the crashes in an effort to better identify the culprit:
EXC_BAD_ACCESS
- Attempted to dereference garbage pointer~JSIExecutor
).publishButtonTappedWithSender
and after that one, publish
or closeWasPressedWithSender
. So, looks like the crash is somehow related to closing the editor, which is actually aligned with the following stack traces and the JSI executor destruction.The following one is the most frequent stack trace I found so dar, which occurs during destruction:
The next one is a bit different and in fact, it doesn't look like that is happening upon editor closing. However, per the last user events, it occurred some seconds after closing the editor.
Additionally, If found other stack traces, less frequent, but also related to closing the editor:
NativeReanimatedModule
.closeWasPressedWithSender
, so the crash happened upon closing the editor, similar to the other crashes.publishButtonTappedWithSender
followed with publish
or closeWasPressedWithSender
.publishButtonTappedWithSender
. However, in this case, there's no publish
action, and even the publishButtonTappedWithSender
action is not included in every Sentry event. This makes me think that the crash is also happening upon closing the editor, but maybe a bit earlier than the rest of the crashes π€ .v1
and v2
of Reanimated.In relation to the previous comment, my plan is to go ahead with the fix provided in this PR on both platforms, which hopefully could help to address the crashes π€.
In relation to the previous comment, my plan is to go ahead with the fix provided in this PR on both platforms, which hopefully could help to address the crashes π€.
That's a great idea, I think that by adding the weakModule
reference might help with this π€
In relation to the https://github.com/WordPress/gutenberg/issues/41686#issuecomment-1158877608, my plan is to go ahead with https://github.com/software-mansion/react-native-reanimated/pull/3185 on both platforms, which hopefully could help to address the crashes π€.
Looks like the C++ side of Reanimated differs by platform, so the fix that was already released for Android might require extra work and potentially won't provide a solution.
In fact, after applying the fix related to using a weak pointer, on iOS, we've managed to reproduce the crash JSCRuntime destroyed with a dangling API object
consistently on development mode:
Interestingly enough, this issue can't be reproduced on production, although, per the stack trace and error message looks very similar to the ones that are listed in this issue's description.
@geriux and I have tried to track down the culprit, but couldn't manage to find a specific part that is causing the crash. Our gut feeling is that Reanimated is affected by some kind of race condition during the Reanimated native module deallocation, which ultimately produces an exception on random occasions. Looks like this type of crash is also encountered by other users of the library, here are some examples:
At this point, we could try upgrading the library to a newer version although we haven't found any specific entry in the new version changelogs for these issues. Alternatively, as mentioned in this comment, it might be worth trying to enable Hermes on iOS, in case it helps in addressing the issue.
@fluiddot were you able to reduce the crashes by enabling hermes on iOS?
were you able to reduce the crashes by enabling hermes on iOS?
Hey @arinjay. ππ» We have not yet enabled Hermes for iOS. We hope to in the future, but I do not believe we have set a schedule for that work at this time.
Don't try to clone an object backed by a different Runtime
- Sentry event: https://sentry.io/share/issue/5070bdca207a4c4c93af5e2123e5653c/
- Affected app version: 19.5.0.4 and newer
- Stacktrace insights: The error message states that it's trying to clone an object backed by a different runtime. This error is a bit odd as we're not using different runtimes, so no clue here about the culprit.
- User action insights: Looks like it's happening upon opening the editor per the last user actions.
- Potential workaround: I found a GitHub comment that outlines a similar stack trace, it states that upgrading to Reanimated 2.6.0 might solve the issue. Another possible culprit might be our version of the React Navigation library, which uses Reanimated and might produce a conflict between using
v1
andv2
of Reanimated.
FYI I created https://github.com/wordpress-mobile/gutenberg-mobile/issues/5862 to track this issue individually.
We are still receiving events related to this crash in the last versions. In fact, it's one of the top 5 crashes on iOS. We've tried different avenues to debug it but the lack of reproduction steps made it difficult to identify the culprit. For this reason, I'd advocate keeping the [Priority] High
label.
Description
On WP-iOS
19.9.0.0
, we identified a crash caused byreact-native-reanimated
and JSI when opening and closing the editor several times. This issue was hard to reproduce, as it looked like that only happened on specific devices and/or OS versions, but we managed to reproduce it almost consistently and released a hotfix (WP-iOS19.9.1.0
) to address it (reference).However, after releasing the hotfix, we noticed that we're still getting crashes related to JSI, although the number is quite lower than the original issue. There's no clue yet about what's causing the crash, so we'd need to investigate it further.
Crash reports
Sentry event -
EXC_BAD_ACCESS
(NOTE: This event is grouping non-related events, so when checking the stack trace verify that is related toPostPostViewController
)Sentry event -
NSt3__112system_errorE
Sentry event -
N8facebook3jsi7JSErrorE
Sentry event -
JSCRuntime destroyed with a dangling API object
UPDATE: We have identified another issue with Reanimated on Android that might be related to this one:
Step-by-step reproduction instructions
We haven't found yet a way to reproduce it, hence no reproduction instructions can be provided.
Expected behaviour
We shouldn't get crash reports related to the
react-native-reanimated
library or JSI.Actual behaviour
We are receiving crash reports related to
react-native-reanimated
and JSI.Screenshots or screen recording (optional)
N/A
WordPress information
Device information