Description
in my application I am publishing and unpublishing the audio and video tracks when user mute / unmute audio and enable / disable the camera. After 2 three continues tap the application is getting crashed.
I tried to disable the mic button interaction until the audio is not published, as we get callback in localParticipantDidPublishAudioTrack but for un-publish there is no callback. That logic is also crashing. How can I fix this crash
Also please suggest what will be the side effect if I will enable/disable the audio track instead of publish / unpublish. Also what is the recommended approach for both audio and video
Steps to Reproduce
While on the call try monkey tap on mute button and from the code inside publish & unpublish the audio track on each respective tap
Code
#IBAction func micControlAction(_ sender: Any) {
//Toggle mic
guard let participant = callViewModel.getCallParticipant(type: .patient) else { return }
if let audioTrack = participant.audioTrack as? LocalAudioTrack {
if audioTrack.isEnabled {
(participant.participant as? LocalParticipant)?.unpublishAudioTrack(audioTrack)
}
else {
(participant.participant as? LocalParticipant)?.publishAudioTrack(audioTrack)
}
audioTrack.isEnabled = !audioTrack.isEnabled
//This will call the observer and the UI will gets updated according to the need
participant.micEnabled.property = audioTrack.isEnabled
}
}
Expected behavior: The user should be able to mute / unmute the mic without any delay.
Actual behavior: Application crashes 100% of time
Logs
libc++abi.dylib: Pure virtual function called!
Pure virtual function called!
Versions
Video iOS SDK 4.6.0 via CocoaPods
Xcode 13.1
iOS Version 13.6.1
iOS Device iPad Air
Based on suggestion on this link, it seems that TwillioVideo 4.6.0 SDK is having issue and reverting to TwillioVideo SDK to version 4.4.0 works fine.
The crash log when using version 4.6.0:
Thread 31 name:
Thread 31 Crashed:
0 libsystem_kernel.dylib 0x00000001ba0e39c4 __pthread_kill + 8
1 libsystem_pthread.dylib 0x00000001f3333434 pthread_kill + 268 (pthread.c:1609)
2 libsystem_c.dylib 0x000000018e562f64 abort + 164 (abort.c:118)
3 libc++abi.dylib 0x000000019bd89bc4 abort_message + 132 (abort_message.cpp:78)
4 libc++abi.dylib 0x000000019bd89594 __cxa_pure_virtual + 24 (cxa_virtual.cpp:16)
5 TwilioVideo 0x0000000105686668 0x104fe4000 + 6956648
6 TwilioVideo 0x000000010568646c 0x104fe4000 + 6956140
7 TwilioVideo 0x0000000105420e0c 0x104fe4000 + 4443660
8 TwilioVideo 0x0000000105420db4 0x104fe4000 + 4443572
9 TwilioVideo 0x0000000105499924 0x104fe4000 + 4938020
10 TwilioVideo 0x0000000105499188 0x104fe4000 + 4936072
11 TwilioVideo 0x0000000105498128 0x104fe4000 + 4931880
12 TwilioVideo 0x0000000105499568 0x104fe4000 + 4937064
13 libsystem_pthread.dylib 0x00000001f332da60 _pthread_start + 148 (pthread.c:890)
14 libsystem_pthread.dylib 0x00000001f332cf5c thread_start + 8
Related
I am having a crash only on one specific scene in my AR Foundation Unity build with the following error.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000020
VM Region Info: 0x20 is not in any region. Bytes before following region: 4362387424
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
__TEXT 10404c000-104050000 [ 16K] r-x/r-x SM=COW ...lycoroTestApp
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [5380]
Triggered by Thread: 28
Thread 28 name:
Thread 28 Crashed:
0 libobjc.A.dylib 0x0000000195ac5ac0 objc_retain + 16 (objc-object.h:636)
1 UnityFramework 0x00000001066d5320 TexturesMetal::AddCreatedTexture(TextureID, id, bool) + 32 (TexturesMetal.mm:481)
2 UnityFramework 0x0000000106634828 GfxDeviceWorker::RunCommand(ThreadedStreamBuffer&) + 21972 (GfxDeviceWorker.cpp:0)
3 UnityFramework 0x00000001066aa2ec GfxDeviceWorkerAutoreleasePoolProxy + 68 (GfxDeviceMetal.mm:5242)
4 UnityFramework 0x0000000106636bd0 GfxDeviceWorker::RunExt(ThreadedStreamBuffer&) + 92 (GfxDeviceWorker.cpp:389)
5 UnityFramework 0x0000000106636b68 GfxDeviceWorker::Run() + 156 (GfxDeviceWorker.cpp:373)
6 UnityFramework 0x000000010662ef70 GfxDeviceWorker::RunGfxDeviceWorker(void*) + 12 (GfxDeviceWorker.cpp:352)
7 UnityFramework 0x00000001062289f8 Thread::RunThreadWrapper(void*) + 496 (Thread.cpp:81)
8 libsystem_pthread.dylib 0x00000001c9777c74 _pthread_start + 288 (pthread.c:887)
9 libsystem_pthread.dylib 0x00000001c977c878 thread_start + 8
At first I thought it was because I was missing the Environmental Probe manager in that scene (no). Then I thought perhaps it was because I was using a specific shader that didn't use a _MainTex. But I use that shader no problem in other working scenes.
And then I built the scene with only a simple primitive and my UI and still received this error. After that crash the scene did open successfully, but obviously the problem is still there. The UI is the exact same as the other working scenes.
I can't find out much about this specific error: TexturesMetal::AddCreatedTexture - only that there may be this bug with GLES3 and PVRTC textures - but they aren't present in the most recent build.
https://issuetracker.unity3d.com/issues/ios-crash-in-uploadtexture-at-texturesmeta-dot-mm-or-drawbufferranges-at-gfxdevicegles-dot-cpp-using-atlas-with-pvrtc-compress
The scene works perfectly in Android - it only crashes in iOS.
Any ideas? Full report below.
I ran a Product>Analysis in Xcode and it gave me this warning:
/Users/xcodeclub/Downloads/Eliot Silver/Classes/UI/UnityView.mm:200:5: nil returned from a method that is expected to return a non-null value
For this bit of Code in UnityView.mm:
static Class UnityRenderingView_LayerClassMTL(id self_, SEL _cmd)
{
return NSClassFromString(#"CAMetalLayer");
}
static Class UnityRenderingView_LayerClassNULL(id self_, SEL _cmd)
{
return NSClassFromString(#"CALayer");
}
#implementation UnityRenderingView
(Class)layerClass
{
return nil;
}
(void)InitializeForAPI:(UnityRenderingAPI)api
{
IMP layerClassImpl = api == apiMetal ? (IMP)UnityRenderingView_LayerClassMTL : (IMP)UnityRenderingView_LayerClassNULL;
class_replaceMethod(object_getClass([UnityRenderingView class]), #Selector(layerClass), layerClassImpl, UIView_LayerClass_Enc);
}
#End
I am using Alamofire and after several hours of my app running on the simulator I got a crash with this error.
*** Terminating app due to uncaught exception 'NSGenericException', reason: 'Start date cannot be later in time than end date!'
I got this stack trace in console:
*** First throw call stack:
(
0 CoreFoundation 0x0000000111186d4b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x0000000110be821e objc_exception_throw + 48
2 Foundation 0x00000001107f0e3c -[_NSConcreteDateInterval dealloc] + 0
3 CFNetwork 0x00000001131a18e8 -[__NSCFURLSessionTaskMetrics _initWithTask:] + 868
4 CFNetwork 0x00000001131a1497 -[NSURLSessionTaskMetrics _initWithTask:] + 100
5 CFNetwork 0x0000000112f77bc7 -[__NSCFURLLocalSessionConnection _tick_finishing] + 351
6 libdispatch.dylib 0x00000001128e3978 _dispatch_call_block_and_release + 12
7 libdispatch.dylib 0x000000011290d0cd _dispatch_client_callout + 8
8 libdispatch.dylib 0x00000001128eae17 _dispatch_queue_serial_drain + 236
9 libdispatch.dylib 0x00000001128ebb4b _dispatch_queue_invoke + 1073
10 libdispatch.dylib 0x00000001128ee385 _dispatch_root_queue_drain + 720
11 libdispatch.dylib 0x00000001128ee059 _dispatch_worker_thread3 + 123
12 libsystem_pthread.dylib 0x0000000112cbc736 _pthread_wqthread + 1299
13 libsystem_pthread.dylib 0x0000000112cbc211 start_wqthread + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Did someone get the similar crash?
Thanks
I had the same crash and did some research today and found this:
http://www.openradar.me/28301343
It looks Apple fixed the issue in iOS 10.2. just thought it may help you!
Yes I just got the same exact crash. It happened in a background thread and it seems to have to do with making a URL session network request. I wonder if it's some sort of multithreading bug having to do with the fact that I'm making two network requests at the same time. I'm using Alamofire as well but not sure if the bug lies in Alamofire or in Apple's code. I've been unable to reproduce it as of now. Maybe you can figure out how to reproduce it and then file an issue in Apple's bug radar or in the Alamofire GitHub repo.
This is a bug in Apple's NSURLSessionTaskMetrics code and happens during a network request when the user's clock gets moved far enough backwards that the request start timestamp is after the request end timestamp. This is reproducible using a network debugging proxy and manually adjusting the clock, and only occurs from iOS 10.0 up to but not including iOS 10.2
If you're using Alamofire, and you don't need NSURLSessionTaskMetrics, you can work around this by using a custom SessionDelegate for your SessionManager and overriding the responds(to aSelector..) function e.g:
class MySessionDelegate: Alamofire.SessionDelegate {
override public func responds(to aSelector: Selector) -> Bool {
let result: Bool = super.responds(to: aSelector)
if #available(iOS 10.2, *) {
// NSURLSessionTaskMetrics date crash is fixed
return result
} else if #available(iOS 10.0, *) {
// NSURLSessionTaskMetrics date crash is not fixed, turn off metric collection
if aSelector == #selector(self.urlSession(_:task:didFinishCollecting:)) {
return false
} else {
return result
}
} else {
// NSURLSessionTaskMetrics doesn't exist
return result
}
}
}
If you're using the default SessionManager (e.g. calling Alamofire.request(...)) you can create your own SessionManager instead in order to use your custom SessionDelegate:
let sessionManager: Alamofire.SessionManager = {
let configuration: URLSessionConfiguration = URLSessionConfiguration.default
configuration.httpAdditionalHeaders = SessionManager.defaultHTTPHeaders
return Alamofire.SessionManager(configuration: configuration, delegate: MySessionDelegate(), serverTrustPolicyManager: nil)
}()
And now instead of calling Alamofire.request(...) you'd call sessionManager.request(...)
I have been struggling with this problem in an os x application for the last few months and have found a workaround.
Background:
Like the OP am using Alamofire to request JSON data via a Timer to send requests several times per second. The data comes in as expected however I get random crashes at irregular intervals with the same message as the OP i.e. Start date cannot be later in time than end date! etc etc.
Solution:
Rather than send Alamofire requests at a regular interval I added some logic which checks for a return of the previous request before sending the next one. This completely eliminated the random crashes.
Hope it helps :)
#thierryb
I'm having a smartwatch app on watchos2. The app always worked but now when it starts I immediately get this error:
Lop_WatchKit_Extension[17535:7854201] *********** ERROR -[SPRemoteInterface _interfaceControllerClientIDForControllerID:] clientIdentifier for interfaceControllerID:447E0002 not found
I found some topics here on stackoverflow but nothing solved the problem.
In my case, this was due to a retain cycle in one InterfaceController of mine.
If you get the logs similar to:
[default] -[SPRemoteInterface
_interfaceControllerClientIDForControllerID:]:0000: ComF: clientIdentifier for interfaceControllerID:XXXXXXXX not found
&/or...
[default] _SendRecordedValues:000: ComF:<-Plugin controller ID
XXXXXXXX has no client identifier
First, figure out which InterfaceController has the controller ID XXXXXXXX.
Have this in awake(withContext:)
override func awake(withContext context: Any?) {
//...
if let id = self.value(forKey: "_viewControllerID") as? NSString {
let strClassDescription = String(describing: self)
print("\(strClassDescription) has the Interface Controller ID \(id)")
}
//...
}
This logs:
[Target.Classname: 0xYYYYYYYY] has the Interface Controller ID
XXXXXXXX
Once you identify the InterfaceController causing these logs, you can continue to debug.
It could be different in your case but in mine I had created a retain cycle with self in one of my closures within which took awhile to locate but I eventually broke the retain cycle with a [weak self] capture.
Basically, the error logs appear when an InterfaceController is trying to execute some code but it has already been released.
What I already had:
DispatchQueue.main.async {
self.doSomethingThatDoesSomethingAsync()
}
What I fixed:
DispatchQueue.main.async { [weak self] in
self?.doSomethingThatDoesSomethingAsync()
}
If you use didSet on any IBOutlets it will also throw this error in the logs.
class MyInterfaceController: WKInterfaceController {
#IBOutlet var myLabel: WKInterfaceLabel! {
didSet {
myLabel.setTitle("Test")
}
}
How #nickromano sad, it's happens when you use didSet with IBOutlets. Cause it's calls before awake(withContext context: Any?)
We can suppress this error if wrap it in DispatchQueue.main.async
#IBOutlet var statusLabel: WKInterfaceLabel! {
didSet {
DispatchQueue.main.async {
self.statusLabel.setHidden(true)
}
}
This has happened to me a few times and more times than not, it is because of a timer that is still firing in a just-previously dismissed WKInterfaceController that I did not catch.
Best thing to do aside from comparing ID's like in #staticVoidMan's answer is to read the call stack. In my case I was able to identify that the old timer was still firing based off these hints:
8 Foundation 0x00007fff214be867 __NSFireTimer + 67
9 CoreFoundation 0x00007fff207a8e3f __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
10 CoreFoundation 0x00007fff207a8912 __CFRunLoopDoTimer + 926
Here is the original call stack (for reference):
<MyApp.InterfaceController: 0x7fb3e4d2d020> has the Interface Controller ID 1EB00002
2021-05-26 14:44:06.632758-0600 MyApp WatchKit Extension[73392:3546879] [default] -[SPRemoteInterface _interfaceControllerClientIDForControllerID:]:2464: ComF: clientIdentifier for interfaceControllerID:1EB00007 not found. callStack:(
0 WatchKit 0x00007fff38d1a268 -[SPRemoteInterface _interfaceControllerClientIDForControllerID:] + 220
1 WatchKit 0x00007fff38d1bfff __54+[SPRemoteInterface setController:key:property:value:]_block_invoke + 340
2 WatchKit 0x00007fff38d12323 spUtils_dispatchAsyncToMainThread + 30
3 WatchKit 0x00007fff38d1be60 +[SPRemoteInterface setController:key:property:value:] + 179
4 WatchKit 0x00007fff38d057af -[WKInterfaceObject _sendValueChanged:forProperty:] + 706
5 WatchKit 0x00007fff38d2a5f8 -[WKInterfaceObject _setImage:forProperty:] + 50
6 MyApp WatchKit Extension 0x000000010955531d $s26MyApp_WatchKit_Extension25ActivityIndicatorDelegateC06handleE5TimeryyF + 813
7 MyApp WatchKit Extension 0x000000010955537a $s26MyApp_WatchKit_Extension25ActivityIndicatorDelegateC06handleE5TimeryyFTo + 42
8 Foundation 0x00007fff214be867 __NSFireTimer + 67
9 CoreFoundation 0x00007fff207a8e3f __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
10 CoreFoundation 0x00007fff207a8912 __CFRunLoopDoTimer + 926
11 CoreFoundation 0x00007fff207a7ec5 __CFRunLoopDoTimers + 265
12 CoreFoundation 0x00007fff207a2546 __CFRunLoopRun + 1949
13 CoreFoundation 0x00007fff207a18be CFRunLoopRunSpecific + 567
14 GraphicsServices 0x00007fff25b49fd3 GSEventRunModal + 139
15 UIKitCore 0x00007fff43290f24 -[UIApplication _run] + 917
16 UIKitCore 0x00007fff43295c0b UIApplicationMain + 101
17 WatchKit 0x00007fff38d0de65 WKExtensionMain + 800
18 libdyld.dylib 0x00007fff20202db5 start + 1
19 ??? 0x0000000000000001 0x0 + 1
)
Have you changed the name of your module? If this is the case then you have to go through your storyboard and update it manually for all the Interfaces you have.
Edit with steps to fix:
Go to the storyboard and for each interface open the Identity inspector, then delete what's in Module and press enter, the new module should get auto-filled.
On sporadic occasions I'm getting an EXC_BAD_ACCESS (SIGSEV) in one of Apple's Accelerator framework methods, vDSP_fft2d_zip. The crash report gave the following for Thread 10. Again, most of the time this works like a champ. Any ideas on how to find the cause and fix it?
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x412f2740
Triggered by Thread: 10
. . .
Thread 10 Crashed:
0 libvDSP.dylib 0x2ddfcdb4 ___lldb_unnamed_function431$$libvDSP.dylib + 68
1 libvDSP.dylib 0x2ddfab66 ___lldb_unnamed_function427$$libvDSP.dylib + 562
2 libvDSP.dylib 0x2ddfa8ee vDSP_fft2d_zop + 434
3 libvDSP.dylib 0x2ddfa732 vDSP_fft2d_zip + 18
4 ASSIST for iPad 0x000ac32e -[Processor setupFilterForBubbleSizeMM:rectWidth:rectImageWidth:dataFilled:dataUnfilled:] (Processor.mm:813)
5 ASSIST for iPad 0x000af4d2 -[Processor runConvolutionProcessOnImage:aveImage:] (Processor.mm:1835)
6 ASSIST for iPad 0x000ac5f6 -[Processor processAnswers] (Processor.mm:869)
7 ASSIST for iPad 0x000ae9cc -[Processor process] (Processor.mm:1644)
8 ASSIST for iPad 0x000d7744 -[ReallTimeScanner processImage:] (ReallTimeScanner.mm:1046)
9 Foundation 0x2f296c82 __NSThread__main__ + 1058
10 libsystem_pthread.dylib 0x396b6c1a _pthread_body + 138
11 libsystem_pthread.dylib 0x396b6b8a _pthread_start + 98
12 libsystem_pthread.dylib 0x396b4c8c thread_start + 4
The relevant code looks like this:
#define FFT_SIZE 512
#define FFT_POWER 9
dataFilledIn->imagp=(float *) malloc(sizeof(float)*FFT_SIZE*FFT_SIZE);
dataFilledIn->realp=(float *) malloc(sizeof(float)*FFT_SIZE*FFT_SIZE);
dataUnfilledIn->imagp=(float *) malloc(sizeof(float)*FFT_SIZE*FFT_SIZE);
dataUnfilledIn->realp=(float *) malloc(sizeof(float)*FFT_SIZE*FFT_SIZE);
memset(dataFilledIn->imagp, 0, sizeof(float)*FFT_SIZE*FFT_SIZE);
memset(dataFilledIn->realp, 0, sizeof(float)*FFT_SIZE*FFT_SIZE);
memset(dataUnfilledIn->imagp, 0, sizeof(float)*FFT_SIZE*FFT_SIZE);
memset(dataUnfilledIn->realp, 0, sizeof(float)*FFT_SIZE*FFT_SIZE);
for(float y=0; y<FFT_SIZE; y+=0.25)
{
for(float x=0; x<FFT_SIZE; x+=0.25)
{
dataFilledIn->realp[(int)y*FFT_SIZE+(int)x] += 0.0625;
dataUnfilledIn->realp[(int)y*FFT_SIZE+(int)x] -= 0.0625;
}
}
vDSP_fft2d_zip(setup, dataFilledIn, 1, 0, FFT_POWER, FFT_POWER, kFFTDirection_Forward);
Answering my own question here: Be sure that the very first parameter sent in (type FFTSetup) to vDSP_fft2d_zip() is initialized correctly, and you should use this call
vDSP_destroy_fftsetup(setup);
to clean it up. I was initializing the setup var properly, like this
setup = vDSP_create_fftsetup(FFT_POWER, kFFTRadix2);
and then cleaning it up, but then was not initializing it again before subsequent calls to vDSP_fft2d_zip(). Unfortunately it only rarely caused a crash, which made it seem like the frequent calls to vDSP_fft2d_zip(setup, . . .) were working when they weren't. The crashes were sporadic making the real cause hard to trace.
There are some articles in Raywenderlich may help you:
Objectively Speaking: A Crash Course in Objective C for iOS 6
Objectively Speaking 2: A Crash Course in Objective C for iOS 6
I'm experiencing crashes from customers, with the following backtrace:
0 libGPUSupportMercury.dylib 0x3542ae2e gpus_ReturnNotPermittedKillClient + 10
1 IMGSGX543RC2GLDriver 0x30bbf5e5 SubmitPacketsIfAny + 245
2 GLEngine 0x32f827db glFinish_Exec + 167
3 CoreImage 0x31fb85b7 CI::GLESContext::recursive_render(CI::Node const*, CGRect, bool) + 219
4 CoreImage 0x31fbb351 CI::GLESContext::render(CI::Node*, CGRect) + 41
5 CoreImage 0x31fc2901 CI::image_get_cgimage(CI::Context*, CI::Image*, CGRect, CGColorSpace*, CI::PixelFormat) + 1313
6 CoreImage 0x31fa8427 -[CIContext createCGImage:fromRect:format:colorSpace:] + 487
7 CoreImage 0x31fa81e9 -[CIContext createCGImage:fromRect:] + 89
8 App 0x0013c9db -[PZTiledImageLayer drawInContext:] (PZTiledImageLayer.m:129)
Which are due to accessing the GPU when the app is in background (not allowed).
The code leading to this crash is this:
if([UIApplication sharedApplication].applicationState == UIApplicationStateActive)
{
cg_image = [self.imageContext createCGImage:im fromRect:rclip];
}
This means the app changes state after my check, but before GPU is accessing within the Core Image API.
What is the proper way of handling the situation of app background state when using this Core Image API?
If this is happening on a background thread, you could try moving it to the main thread. That way the execution of this function is not interleaved with the AppDelegate callback
- (void)applicationDidEnterBackground:(UIApplication *)application
and you can implement some signalling there without worrying about concurrency.