My iOS device logs (on simulator and real devices) was filled with a couple dozen lines of the following error spam:
CFNetwork internal error (0xc01a:/BuildRoot/Library/Caches/com.apple.xbs/Sources/CFNetwork_Sim/CFNetwork-758.0.2/ProjectRuntime/CFNetworkInternal.h:478)
Why am I seeing these, and how do I get rid of them?
Turns out this was due to an incorrect setup in my Info.plist's NSAppTransportSecurity.
Make sure that for each of the NSExceptionDomains you use, the subfields of the dictionary (such as NSIncludesSubdomains, NSExceptionRequiresForwardSecrecy, and NSExceptionAllowsInsecureHTTPLoads) are set to type Boolean, not String. While XCode may display your values of YES and NO very similarly, the type is important for ensuring CFNetwork is able to understand your config without any errors.
Incorrect:
Correct:
Related
while running my iOS app i get the message:
2017-11-04 15:33:02.873595+0100 DagBoek[71486:4321269] ***
-[NSKeyedUnarchiver initForReadingWithData:]: data is NULL
in the XCODE console
DagBoek[71486:4321269] What do the numbers between the brackets mean ?
Can they help me to find where in my code the problem is ?
Thanks
No, they don't really help much. The first number, 71486 in your example, is the process ID (PID). The second number (4321269) is a thread ID of sorts, but Apple's diagnostic and debugging tools seem to use different thread ID schemes in different contexts, so it's mostly useless.
Usually when I set lldb watchpoints, when they're hit, lldb says watchpoint hit old value: new value. However, I set a watchpoint on an address that seems to be getting written to inside a 3rd party library (libjpeg-turbo) and instead of the usual watchpoint hit, I'm seeing EXC_BREAKPOINT code=258, subcode=0xADDRESS.
In all cases, I can see that the subcode must be the address, as it's always equal to the address or close to the one I set the watchpoint to. Can anyone confirm this?
If I delete the watchpoint and keep going, lldb won't pause with EXC_BREAKPOINT. But what does the code mean and where can I find some offical documentation on this?
The exc_types.h doesn't give any detailed information on it.
For anyone who is interested in this question there is a nice article about the topic:
Understanding iOS Exception Types
In all cases, I can see that the subcode must be the address, as it's always equal to the address or close to the one I set the watchpoint to. Can anyone confirm this?
There is not much information in exception_types.h headers:
open -t /Applications/Xcode.app//Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/mach/exception_types.h
I can confirm that I always see EXC_BREAKPOINT to have address in subcode.
However other types in the header say that subcode can have different kinds of information:
#define EXC_EMULATION 4 /* Emulation instruction */
/* Emulation support instruction encountered */
/* Details in code and subcode fields */
We had to investigate on one Swift crash that produced: EXC_BREAKPOINT. In our case it boiled down to Swift type coercions. Both of the following cause EXC_BREAKPOINT on ARM devices:
func test_crash() {
let num = Int(DBL_MAX)
}
func test_crash_2() {
let num = Int(Double(0) / Double(0))
}
In both of these cases EXC_BREAKPOINT has a subcode with an address which is the address of sbrk instruction if you look at the assembly.
exc_types.h only has the architecture independent parts of the exception definitions. You need to look in the i386/arm subdirectories to find the architecture specific parts. If you are on Yosemite, the arm directory won't be in /usr/include/mach, you'll have to look for it in the iPhoneOS SDK inside of Xcode.app. Anyway, mach/arm/exception.h says:
#define EXC_ARM_DA_DEBUG 0x102 /* Debug (watch/break) Fault */
And as you suspect the subcode is the address of the access.
But lldb doesn't report bare exceptions if it recognizes the exception as implementing some higher level task. In this case, it should be reporting the stop reason as a watchpoint hit. For some reason it doesn't recognize this as your watchpoint. Is the subcode address exactly the same as the one reported by watch list?
I'm new to lldb and trying to diagnose an error by using po [$eax class]
The error shown in the UI is:
Thread 1: EXC_BREAKPOINT (code=EXC_i386_BPT, subcode=0x0)
Here is the lldb console including what I entered and what was returned:
(lldb) po [$eax class]
error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0xb06b9940).
The process has been returned to the state before expression evaluation.
The global breakpoint state toggle is off.
You app is getting stopped because the code you are running threw an uncaught Mach exception. Mach exceptions are the equivalent of BSD Signals for the Mach kernel - which makes up the lowest levels of the macOS operating system.
In this case, the particular Mach exception is EXC_BREAKPOINT. EXC_BREAKPOINT is a common source of confusion... Because it has the word "breakpoint" in the name people think that it is a debugger breakpoint. That's not entirely wrong, but the exception is used more generally than that.
EXC_BREAKPOINT is in fact the exception that the lower layers of Mach reports when it executes a certain instruction (a trap instruction). That trap instruction is used by lldb to implement breakpoints, but it is also used as an alternative to assert in various bits of system software. For instance, swift uses this error if you access past the end of an array. It is a way to stop your program right at the point of the error. If you are running outside the debugger, this will lead to a crash. But if you are running in the debugger, then control will be returned to the debugger with this EXC_BREAKPOINT stop reason.
To avoid confusion, lldb will never show you EXC_BREAKPOINT as the stop reason if the trap was one that lldb inserted in the program you are debugging to implement a debugger breakpoint. It will always say breakpoint n.n instead.
So if you see a thread stopped with EXC_BREAKPOINT as its stop reason, that means you've hit some kind of fatal error, usually in some system library used by your program. A backtrace at this point will show you what component is raising that error.
Anyway, then having hit that error, you tried to figure out the class of the value in the eax register by calling the class method on it by running po [$eax class]. Calling that method (which will cause code to get run in the program you are debugging) lead to a crash. That's what the "error" message you cite was telling you.
That's almost surely because $eax doesn't point to a valid ObjC object, so you're just calling a method on some random value, and that's crashing.
Note, if you are debugging a 64 bit program, then $eax is actually the lower 32 bits of the real argument passing register - $rax. The bottom 32 bits of a 64 bit pointer is unlikely to be a valid pointer value, so it is not at all surprising that calling class on it led to a crash.
If you were trying to call class on the first passed argument (self in ObjC methods) on 64 bit Intel, you really wanted to do:
(lldb) po [$rax class]
Note, that was also unlikely to work, since $rax only holds self at the start of the function. Then it gets used as a scratch register. So if you are any ways into the function (which the fact that your code fatally failed some test makes seem likely) $rax would be unlikely to still hold self.
Note also, if this is a 32 bit program, then $eax is not in fact used for argument passing - 32 bit Intel code passes arguments on the stack, not in registers.
Anyway, the first thing to do to figure out what went wrong was to print the backtrace when you get this exception, and see what code was getting run at the time this error occurred.
Clean project and restart Xcode worked for me.
I'm adding my solution, as I've struggled with the same problem and I didn't find this solution anywhere.
In my case I had to run Product -> Clean Build Folder (Clean + Option key) and rebuild my project. Breakpoints and lldb commands started to work properly.
Sometimes I get this error on the device.
I've seen past question on this saying the error will occur if simulation location is enabled in the scheme. However I'm getting this on hardware not the simulator.
Other answer say to check there is Wifi/3G. Which there is.
Other answer say to reset the location services and the network services. However this would imply some terminal fault with the device, but after getting this error I might try again later and it would work.
From Apple Docs,
typedef enum {
kCLErrorLocationUnknown = 0,
kCLErrorDenied,
kCLErrorNetwork,
kCLErrorHeadingFailure,
kCLErrorRegionMonitoringDenied,
kCLErrorRegionMonitoringFailure,
kCLErrorRegionMonitoringSetupDelayed,
kCLErrorRegionMonitoringResponseDelayed,
kCLErrorGeocodeFoundNoResult,
kCLErrorGeocodeFoundPartialResult,
kCLErrorGeocodeCanceled,
kCLErrorDeferredFailed,
kCLErrorDeferredNotUpdatingLocation,
kCLErrorDeferredAccuracyTooLow,
kCLErrorDeferredDistanceFiltered,
kCLErrorDeferredCanceled,
} CLError;
kCLErrorDomain error comes unexpectedly, reason may be different. You are getting the error 0; i.e kCLErrorLocationUnknown the location manager was unable to obtain a location value right now.
I'm serializing an array of dictionaries to a string and it seems that it causes issues on the generation of the diff… or something… I've been seeing a lot of these:
AssertMacros: hash <= (~(UniChar)0x00), Hash value has exceeded UniCharMax! file: /Users/…/Pods/Google-Diff-Match-Patch/DiffMatchPatchCFUtilities.c, line: 391
I didn't look very deep but I didn't understood what am I doing wrong…
Also, I'm having a lot of 440 errors that sometimes appear with the error above. How can I handle these errors? Shouldn't the framework send the full object when the 440 pops up?
Thanks!
Error 440 means 'Invalid Diff'. After checking DiffMatchPatch, it seems that the error you're seeing is caused by an excesively large array of diffs (which, in this case, seems to be a Diff Match Patch internal issue).
Please, take a look at this pull request, which already implements the mechanism you're currently working on: https://github.com/Simperium/simperium-ios/pull/121
Specifically, NSArray+Simperium, SPMemberJsonList and SPJsonDiff contain logic to handle DiffMatchPatch.