Identifying privacy violation in iOS 10 - ios

I am facing random crashes in my application running on iOS 10.2. Attached my crash log below. I have checked few forums and some answers suggests to include missing permissions in info.plist. But I have already added the necessary privacy access keys and still I'm facing the issue. Im not sure which is the cause for the privacy violence issue. Is there a way to identify which key i have missed to add in info.plist from the log or in any other way?
0 libsystem_kernel.dylib 0x182b59d74 __abort_with_payload + 8
1 libsystem_kernel.dylib 0x182b5649c abort_with_payload_wrapper_internal + 100
2 libsystem_kernel.dylib 0x182b564c8 system_set_sfi_window + 10
3 TCC 0x185dca328 __TCCAccessRequest_block_invoke_2.80 + 258
4 TCC 0x185dca224 __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 702
5 TCC 0x185dcd330 __tccd_send_block_invoke + 348
6 libxpc.dylib 0x182c5efcc _xpc_connection_reply_callout + 80
7 libxpc.dylib 0x182c5ef3c _xpc_connection_call_reply + 40
8 libdispatch.dylib 0x182a161bc _dispatch_client_callout + 16
9 libdispatch.dylib 0x182a24a4c _dispatch_queue_override_invoke + 732
10 libdispatch.dylib 0x182a2634c _dispatch_root_queue_drain + 572
11 libdispatch.dylib 0x182a260ac _dispatch_worker_thread3 + 124
12 libsystem_pthread.dylib 0x182c1f2a0 _pthread_wqthread + 1288
13 libsystem_pthread.dylib 0x182c1ed8c start_wqthread + 4

What I did in my case is I added every single Privacy permission possible and labelled them with what they requested, like "Bluetooth" for the permission to access Bluetooth accessories. Then I ran the app and watched for which permission request came in. It took me a few minutes to add them all in but it solved my issue. In the end, I had requested Photo Library Access but had forgotten to request Photo Library Addition, that permission was only required when a user attempted to share an image and then hit the option "Save" instead of actually sharing it via SMS/Email/*

TCCAccessRequest Belongs to the keyboard extension. If you access other things from within, it requires full access else it get terminated.
If its not full access the cause could mean another access right. Full access include a lot privileges like location.

I believe TCC __TCCAccessRequest_block_invoke_2.80 is related to NSMicrophoneUsageDescription. See How do I prevent a WKWebView from presenting the Camera modal if a user has denied access to the camera? for why this may be happening.
My best educated guess is that the 2.80 is some internal constant related to the particular privacy permissions. In this case, microphone permissions.

Related

App crashes when running on iPhone with violations as exception

Thread 1 Crashed:
0 libsystem_kernel.dylib 0x1e81a458 __abort_with_payload + 24
1 libsystem_kernel.dylib 0x1e817dd9 system_set_sfi_window + 1
2 TCC 0x20f27c4f __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 229
3 TCC 0x20f27b6b __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 1
4 TCC 0x20f2a383 __tccd_send_block_invoke + 339
5 libxpc.dylib 0x1e90215f _xpc_connection_reply_callout + 47
6 libxpc.dylib 0x1e902101 _xpc_connection_call_reply + 27
7 libdispatch.dylib 0x1e72649b _dispatch_queue_override_invoke + 605
8 libdispatch.dylib 0x1e727a91 _dispatch_root_queue_drain + 379
9 libdispatch.dylib 0x1e7278b7 _dispatch_worker_thread3 + 107
10 libsystem_pthread.dylib 0x1e8ce937 _pthread_wqthread + 1169
11 libsystem_pthread.dylib 0x1e8ce48c start_wqthread + 8
Exception Type: EXC_CRASH (SIGABRT) Exception Codes:
0x0000000000000000, 0x0000000000000000 Exception Note:
EXC_CORPSE_NOTIFY
Termination Reason: TCC, This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSMicrophoneUsageDescription key with a string value explaining to the user how the app uses this data.
Triggered by Thread: 1
I don't know what permissions i need to add.
iOS 10 onwards, when you access privacy sensitive resources like camera, microphone you should add usage description text to info.plist.
This text will be shown in alert asking user to grant permission to access the resource when your code tries to access the resource for the first time.
So you should put appropriate message explaining why your app needs the resource :)
Add key NSMicrophoneUsageDescription and a text description to info.plist and it will not crash again :)
Just add NSMicrophoneUsageDescription key & in value add the justification that why your app is using Microphone. This is the latest requirement in iOS 10.
Just add "NSMicrophoneUsageDescription " in info plist which will allow to private data access from the microphone needed.

Why IOS terminates application with call clientSystemApplicationTerminated

My IOS application has many threads, usually 60.
and of of them sometimes (very rarely) receives next:
11 libsystem_c.dylib 0x0000000180fb5364 exit + 20
12 FrontBoardServices 0x0000000182e86fb4 -[FBSWorkspace clientSystemApplicationTerminated:] + 24
13 libdispatch.dylib 0x0000000180f494bc _dispatch_call_block_and_release + 20
14 libdispatch.dylib 0x0000000180f4947c _dispatch_client_callout + 12
15 libdispatch.dylib 0x0000000180f554c0 _dispatch_queue_drain + 860
16 libdispatch.dylib 0x0000000180f4cf80 _dispatch_queue_invoke + 460
17 libdispatch.dylib 0x0000000180f57390 _dispatch_root_queue_drain + 724
18 libdispatch.dylib 0x0000000180f570b0 _dispatch_worker_thread3 + 108
this thread is not 'main'-thread with UI.
and call 'clientSystemApplicationTerminated' invokes 'exit' from libC.
This would unexpectedly destroy (calls destructors) all static/global objects in application while application handles some data from network.
This absolutely unexpected way to terminate iOS application and I will ask help to understand this surprisingly logic to terminate an iOS-app.
In every case I've seen, this indicates an OS bug and is often related to an impending OS crash. Search for "Terminating since there is no system app" which is very likely in the logs (if you disassemble the simulator code for this method, that's what's logged immediately prior to calling exit). Some example discussions of this message:
https://forums.developer.apple.com/thread/20240
App Crashing Entire Device On Segue for iOS 9 + Xcode 7
https://forums.developer.apple.com/thread/18164

How Can I symbolicate the coding error?

The following is the thread that causes my app to crash when it resumes from idle. I tried plugging in my iPhone, going to organizer, clicking on the iPhone, and going to device logs. But when I click Re-Symbolicate, nothing happens. Please advise and provide detailed directions to symbolicate so I can find the cause of the crash. I tried looking up how to symbolicate but I was unsuccessful.
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3b8fa350 __pthread_kill + 8
1 libsystem_c.dylib 0x3b87111e pthread_kill + 54
2 libsystem_c.dylib 0x3b8ad96e abort + 90
3 libc++abi.dylib 0x3ae4bd4a abort_message + 70
4 libc++abi.dylib 0x3ae48ff4 default_terminate() + 20
5 libobjc.A.dylib 0x3b3fca74 _objc_terminate() + 144
6 libc++abi.dylib 0x3ae49078 safe_handler_caller(void (*)()) + 76
7 libc++abi.dylib 0x3ae49110 std::terminate() + 16
8 libc++abi.dylib 0x3ae4a594 __cxa_rethrow + 84
9 libobjc.A.dylib 0x3b3fc9cc objc_exception_rethrow + 8
10 CoreFoundation 0x3369df1c CFRunLoopRunSpecific + 452
11 CoreFoundation 0x3369dd44 CFRunLoopRunInMode + 100
12 GraphicsServices 0x372612e6 GSEventRunModal + 70
13 UIKit 0x355b32fc UIApplicationMain + 1116
14 FitGoal 0x00080cc0 0x7a000 + 27840
15 libdyld.dylib 0x3b833b1c tlv_initializer + 4
Symbolication doesn't work because the dSYM and app binary that caused the crash cannot be found using Spotlight or either of the two files is missing.
Symbolication would only reveal that frame #14 is a call to main.m, which doesn't help you.
The crash is caused by an exception. To find the cause of the crash you would need to have the Application Specific Information block in the report that tells you which exception was raised, and also the Last Exception Backtrace which would show you where the exception happened in the code. Both parts are usually missing in iOS crash reports from Apple.
To find the cause of the crash you have to:
Add an exception breakpoint.
Start the app with the debugger in Xcode running (Menu Product - Run)
Reproduce the scenario that triggered the crash.
I think that you have tested in Release mode. In that mode, the default value of "Strip Debug Symbols During Copy" is YES.
If this option is enable (YES), you must have the .dsym file in order to symbolicate, other wise, you have to disable it (NO).
Search google about "Strip Debug Symbols During Copy".

Interpreting iPhone Crash Log / Stack Trace

I'm using the TestFlight SDK and have received several crash reports identical to this one. However, I'm having trouble understanding it, and what the underlying cause of the crash is from the reports?
Exception
SIGSEGV
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60...
Exception reason
SIGSEGV
Stacktrace
0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
8 MyAppName 0x000b7168 MR_swapMethodsFromClass + 18076
9 CoreData 0x35e0dbc0 developerSubmittedBlockToNSManagedObjectContextPerform + 88
10 libdispatch.dylib 0x335974b6 _dispatch_client_callout + 22
11 libdispatch.dylib 0x33598dca _dispatch_main_queue_callback_4CF$VARIANT$up + 226
12 CoreFoundation 0x31e79f3a __CFRunLoopRun + 1290
13 CoreFoundation 0x31decebc CFRunLoopRunSpecific + 356
14 CoreFoundation 0x31decd48 CFRunLoopRunInMode + 104
15 GraphicsServices 0x36e092ea GSEventRunModal + 74
16 UIKit 0x320db2f8 UIApplicationMain + 1120
17 MyAppName 0x00099122 main (main.m:17)
18 MyAppName 0x000990d7 start + 39
Additional details:
Users report this crash happens 1-2 seconds after the app starts
The app uses Core Data and MagicalRecord (which is where the MR_swapMethodsFromClass method comes from)
I can't reproduce this issue on any test devices when running from Xcode (iPhone 3GS, iPhone 4, or iPhone 5) running various iOS versions (iOS 5.1, 6.0, 6.1)
EDIT
Still working on solving this issue... I've been able to recreate it (but not with a debugger attached).
Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.
However, if they first delete the old app and install the update, the error doesn't occur.
Let's walk through it:
0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
That's TestFlight. This is after the crash has happened, so it's certainly not the cause.
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
This is the point at which we caught the crash. "sigtramp" is the signal "trampoline." That's a fancy way of saying "I caught a signal (crash) and now I'm going to bounce to somewhere else in the code."
3 Foundation 0x33750d1c -[NSError dealloc] + 60
Ah. This is important. We crashed while deallocating an NSError. That means the NSError was over-released or under-retained.
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
Sad… it manifested while draining the autorelease pool. That means the actual bug could be a long way from here. But at least we know the type of the object. NSZombies could be of use to try to find the specific object.
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
And the autorelease pool was draining during a MOC save. That suggests it's probably related to your Core Data code. It's at least where you'd look first.
The things to remember are:
The bug is almost certainly in your code.
If it's not in your code, it's probably in Magical Record
Do not assume it is in Core Data. That is the least likely place for the bug given this stack.
Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.
However, if they first delete the old app and install the update, the error doesn't occur.
Probably in your upgrade code then. Most likely in the Core Data migration stuff. Audit every use of NSError in that area of code. Eliminate all compiler and analyzer warnings. And try NSZombies if its reproducible.
You should try to add a model version to your data model. It worked for me, i had a similar Magical-Record-related issue.

How to understand and solve crash report: SIGSEGV, SEGV_ACCERR

I am getting sometimes this crash report:
Name: SIGSEGV
Reason: SEGV_ACCERR
Stack Trace:
0 MyApp 0x00070456 0x1000 + 455766
1 MyApp 0x0007a34d 0x1000 + 496461
2 MyApp 0x0007a4f1 0x1000 + 496881
3 MyApp 0x000d31dd 0x1000 + 860637
4 MyApp 0x00067f0f 0x1000 + 421647
5 MyApp 0x0005ad69 0x1000 + 367977
6 MyApp 0x000081e3 0x1000 + 29155
7 MyApp 0x00008ae9 0x1000 + 31465
8 CoreFoundation 0x35a547e4 __invoking___ + 68
9 CoreFoundation 0x359af7b1 -[NSInvocation invoke] + 160
10 Foundation 0x3556268f -[NSInvocationOperation main] + 114
11 Foundation 0x354fb393 -[__NSOperationInternal start] + 862
12 Foundation 0x35564793 __block_global_6 + 102
13 libdispatch.dylib 0x348dec59 _dispatch_call_block_and_release + 12
14 libdispatch.dylib 0x348e1817 _dispatch_worker_thread2 + 258
15 libsystem_c.dylib 0x32e0edfb _pthread_wqthread + 294
I don't understand this crash report. Also I don't know when this is happening.
Is there a way to find out more about this crash?
How can i solve this issue?
You need to symbolicate the crash report, which will convert the addresses in line 0 to 7 into meaningfull classes, methods and line numbers. Usually Xcode does that automatically if you still have the binary of the build that caused the crash around.
The SIGSEV error is a signal send when you try to get memory that you are not allowed to touch
The best way to solve this problem is to put a breakpoint and jump line per line in order to find the line which is the problem
Or you can also put some Debug Logs to see were is the problem
For understand what SIGSEV or SEGV_ACCERR mean, you can search on internet more informations ;)
Question is old but there is better way then John Smith answer.
Currently the best approach is run using profiler (in XCode: Product/Profile) using respective template.
Most probably you need to use "Zombies" template which is now also supported on device :) not only on emulator.
When using this tool you have grater chance for spotting incorrect use of memory.

Resources