Recently I add a broadcast upload extension to my host app to implement system wide screen cast.I found the broadcast upload extension sometimes stopped for unknown reason.If I debug the broadcast upload extension process in Xcode, it stopped without stopping at a breakpoint（If the extension is killed for 50M bytes memory limit, it will stopped at a breakpoint, and Xcode will point out that it's killed for 50M bytes memory limit）.For more imformation, I read the console log line by line.Finally, I found a significant line: osanalyticshelper Process replayd [26715] killed by jetsam reason highwater It looks like the ReplayKit serving process 'replayd' is killed by jetsam, and the reason is 'highwater'.So I searched the internet for more imformation.And I found a post: https://www.jianshu.com/p/30f24bb91222 After reading that,I checked the JetsamEvent report in device, and found that when the 'replayd' process was killed it occupied 100M bytes memory.Is there a 100M bytes memory limit for 'replayd' process?How can I avoid it to occupy more than 100M bytes memory? Further more, I found that this problem offen occured if the previous extension process is stopped via RPBroadcastSampleHandler's finishBroadcastWithError method.If I stop the extension via control center button, this rarely occured.

Since we need webrtc's audio processing module functionality, we build an webrtc framework with the symbols of audio processing module all visible.When we use this webrtc framework to archive a package to apple app store, an error is reported: The app references non-public symbols in Payload/Doctor.app/Doctor: __ZN3rtc18webrtc_checks_impl8FatalLogEPKciS2_PKNS0_12CheckArgTypeEz With error code STATE_ERROR.VALIDATION_ERROR.11 for id b721c24c-9c42-4742-ba79-8eddb4fd9c5a This error seems to say that we use a non-public symbol 'webrtc_checks_impl::FatalLog'.We indeed use these symbol, this symbol corresponds to a function in 'checks' library, which is a commonly used function in webrtc inner modules.We nearly can't kick it out from webrtc framework. Besides, I'm curiously why the archive checking process refuse us for this error,why we can't use this function in our framework?Is this a bug in Xcode archiving process?

I use GLKView's display to render video images. If I debugging my app with xcode, after about an hour the main thread is suspanded by GLKView's display method, which fanally called 'nanosleep' in it's stack.After the main thread is stucked, other threads seems running well.The whole stack is like: #0 0x00000001afb79d00 in _semwaitsignal () #1 0x000000018e5dd714 in nanosleep () #2 0x000000018e5dd5ec in usleep () #3 0x00000001046000c8 in -[DYSharedMemoryTransport waitEAGAIN] () #4 0x0000000104622b70 in -[DYBaseStreamTransport writeBuffers:] () #5 0x00000001046230d0 in -[DYBaseStreamTransport sendMessage:error:] () #6 0x0000000104612a74 in 63-[DYTransport send:inReplyTo:error:replyQueue:timeout:handler:]blockinvoke.153 () #7 0x00000001044715fc in dispatchclientcallout () #8 0x0000000104480cd8 in dispatchsyncinvokeandcompleterecurse () #9 0x00000001046128f0 in -[DYTransport send:inReplyTo:error:replyQueue:timeout:handler:] () #10 0x00000001045fee80 in -[DYSharedMemoryTransport send:inReplyTo:error:replyQueue:timeout:handler:] () #11 0x0000000102d825f0 in handleframeboundary () #12 0x0000000102f31e5c in EAGLContextPresentInterposeCommon(EAGLContext*, unsigned int, unsigned long, double, bool () blockpointer) () #13 0x0000000102f2fdc8 in EAGLContextpresentRenderbuffer(EAGLContext*, objcselector*, unsigned long) () #14 0x00000001b4166d7c in -[GLKView display:] () #15 0x0000000103176e18 in _29-[RTCEAGLVideoView configure]blockinvoke at /Users/huhai/dev/webrtc/svn/iOSm83/native/source/src/sdk/objc/components/renderer/opengl/RTCEAGLVideoView.m:133 #16 0x000000010460acb0 in -[DYDisplayLinkInterposer forwardDisplayLinkCallback:] () #17 0x0000000188a99eac in CA::Display::DisplayLink::dispatchitems(unsigned long long, unsigned long long, unsigned long long) () #18 0x000000018feb4f28 in IODispatchCalloutFromCFMessage () #19 0x00000001858f387c in CFMachPortPerform () #20 0x0000000185916a70 in CFRUNLOOPISCALLINGOUTTOASOURCE1PERFORMFUNCTION () #21 0x0000000185915e84 in CFRunLoopDoSource1 () #22 0x0000000185910054 in CFRunLoopRun () #23 0x000000018590f200 in CFRunLoopRunSpecific () #24 0x000000019ba0a598 in GSEventRunModal () #25 0x00000001881d5004 in -[UIApplication run] () #26 0x00000001881da5d8 in UIApplicationMain () #27 0x0000000100d690f8 in main at /Users/huhai/dev/projects/svn/311videochat/videochat/demo/iOS/LMVideoChatDemo/LMVideoChatDemo/main.m:14 #28 0x00000001855ee598 in start () This problem seems not happen when not debugging.I searched the google, but found just only one post talking about this problem:https://stackoverflow.com/questions/58215087/glkviewcontroller-hangs-after-a-few-hours