Memory related crash after media upload

[staskus]

Description

Parent issue: #20859

This issue requires more investigation. A crash with such a trace could indicate memory issues when observing objects without deinitializing the observer. By looking at app logs, we can see media upload happening and finishing before a KVO_IS_RETAINING_ALL_OBSERVERS_OF_THIS_OBJECT_IF_IT_CRASHES_AN_OBSERVER_WAS_OVERRELEASED_OR_SMASHED crash.

Sentry issues

https://a8c.sentry.io/issues/3138940981/events/7b69e5ef94aa4e77b71fd6b29af1825b/?project=5716771
https://a8c.sentry.io/issues/3138940981/events/2379e20947804bda80962e97177426f3/?project=5716771
https://a8c.sentry.io/issues/3138940981/events/451fdac6b0bf4a66a1ed3b9ba8abbf9a/?project=5716771
https://a8c.sentry.io/issues/3138940981/events/67f54ca6c0094f4daf1651ea98932c75/?project=5716771
https://a8c.sentry.io/issues/3138940981/events/2fa17114d4e143819ac1500f036d2ab6/?project=5716771

Logs

Stack trace

initWithOptions:capacity: >
KERN_INVALID_ADDRESS at 0x1e.

Thread 0 Crashed:
0   libobjc.A.dylib                 0x324c6a4bc         object_isClass
1   Foundation                      0x3270c2078         KVO_IS_RETAINING_ALL_OBSERVERS_OF_THIS_OBJECT_IF_IT_CRASHES_AN_OBSERVER_WAS_OVERRELEASED_OR_SMASHED
2   Foundation                      0x3270f96cc         NSKeyValueWillChangeWithPerThreadPendingNotifications
3   AVFCore                         0x351c1d314         __31-[AVPlayerItem _updateTimebase]_block_invoke_2
4   libdispatch.dylib               0x3414c831c         _dispatch_call_block_and_release
5   libdispatch.dylib               0x3414c9ea8         _dispatch_client_callout
6   libdispatch.dylib               0x3414d86a0         _dispatch_main_queue_drain
7   libdispatch.dylib               0x3414d82f0         _dispatch_main_queue_callback_4CF
8   CoreFoundation                  0x332bc6c24         __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
9   CoreFoundation                  0x332ba855c         __CFRunLoopRun
10  CoreFoundation                  0x332bad3e8         CFRunLoopRunSpecific
11  GraphicsServices                0x3a95b5358         GSEventRunModal
12  UIKitCore                       0x336fa96e4         -[UIApplication _run]
13  UIKitCore                       0x336fa9348         UIApplicationMain
14  Jetpack                         0x204f75328         main (main.swift:7)
15  <unknown>                       0x1cb08edec         <redacted>

App Logs

2023-06-12 11:17:48:244 Post Coordinator -> Media state: Progress: 0.9982957538795946
2023-06-12 11:17:48:371 Post Coordinator -> Media state: Progress: 0.9999999756470167
2023-06-12 11:17:55:216 🔵 Tracked: media_service_upload_successfu 2023-06-12 11:17:55:234 Post Coordinator -> Media state: Progress: 1.0 

Steps to reproduce the behavior

Haven't reproduced it

Tested on [device], iOS [version], Jetpack iOS / WordPress iOS [version]

[crazytonyli]

This is potentially an issue in react-native-video. See TheWidlarzGroup/react-native-video#2122. I'm still looking though.

[crazytonyli]

TheWidlarzGroup/react-native-video#1956 (comment) has exactly the same stacktrace.

[staskus]

react-native-video/react-native-video#1956 (comment) has exactly the same stacktrace.

@crazytonyli, great catch!

This was the workaround for the linked issue:

We noticed that the crash happens if we try to change the source URL of react-native-video component very quickly after setting it with some other value. Once we made sure that we don't do that the crashes stopped.

[SiobhyB]

With Automattic/jetpack#35637, we should see a decrease in this crash in 24.4, as the video block will be replaced with the VideoPress v5 block for dotcom and Jetpack-connected users on the Jetpack app. As explained at Automattic/jetpack#35637 (comment), we were able to reproduce and implement a fix for the crash as part of v5's implementation.

We'll still need to look into a fix for the core video block, as self-hosted users may still run into the crash and VideoPress v5 won't run at all in the WordPress app.