This is driving me crazy...
I have been using Google Maps SDK for iOS for a while (even in an App Store product).
Now, I cannot make it run in the iOS simulator any longer! It doesn't matter which project I try to run (even the sample code from the SDK), it will always crash the first time a map is added, e.g.:
self.view = [GMSMapView mapWithFrame: frame camera: camera];
This is the log messages I get:
2013-05-16 10:59:01.047 SDKDemos[939:1303] ADDRESPONSE - ADDING TO MEMORY ONLY: http://dl.google.com/geosdk/latest
2013-05-16 10:59:01.050 SDKDemos[939:1b03] Google Maps SDK for iOS version: 1.2.2.3031
2013-05-16 10:59:01.050 SDKDemos[939:1b03] New version of Google Maps SDK for iOS available: 1.3.0.3430
2013-05-16 10:59:01.111 SDKDemos[939:c07] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
I have lately tried an antivirus SW on this mac, so one theory is that it may have blocked some vital Google Maps data from downloading. Now, I have uninstalled this anti-virus SW, removed Xcode's DerivedData and reset the iOS Simulator, but with the same disappointing result.
All projects I have tried are working perfectly fine when I run them on my iPhone. I have also another mac where everything works fine on the simulator. So clearly something must have happened with this particular machine.
Any advice?
Update
Initially, I focused entirely on the first warning message (ADDRESPONSE - ADDING TO MEMORY ONLY: http://dl.google.com/geosdk/latest), but I have now realised that the only purpose of the URL mentioned there is to download a string with the latest SDK version number (currently "1.3.0.3430"). Since the SDK then correctly prints that string two lines further down, I find it very unlikely that this line is related to the real cause of the crash. (I have changed the title of this question accordingly.)
Hard to say if this really qualifies as an answer...
In any case, I'd like to document the outcome of this, in case someone else stumbles upon the same problem in the future:
After having been away a couple of days, I returned today, turned on my iMac, made a new test run, and...
The problem was gone!
Everything just worked as expected!
I have not changed a single line of code or anything at all in the Xcode configuration.
The only thing I did was to once again delete Xcode's DerivedData and reset the simulator (which I did numerous times last week, but without success at that time).
I guess that my assumption must have been right, that there must have been a cache somewhere in my machine, but outside Xcode´s DerivedData, that caused this problem. Then I was away a couple of days, and this cache simply timed out!
Even if this may sound a bit far-fetched, I cannot think of another reason for this weird behaviour.
It would have been really useful to know where this cache is located, so that one could clean it up without needing to shut down the mac for some days!
Related
Since today I can't run a CN1 debug the app on my iPhone 4 (iOS 9.3.5). It crashes on startup.
I've made only minor changes:
Add a button which uses execute(URL) to open a URL.
and I've got this exception:
Library not loaded
/System/Library/Frameworks/UserNorifications.framework/UserNotifications
[...]
Reason: image not found.
Can you help me, please?
That's probably a regression due to changes that went in to implement https://github.com/codenameone/CodenameOne/issues/2208
It's probably due to this commit: https://github.com/codenameone/CodenameOne/commit/a3a70fadd7dbef661351d11dc35683be3d828eda
Can you please file an issue to keep track on this?
We're looking into it.
After working just fine on both iPhone and iPad for a month, my Xcode 9 app has consistently started crashing causing me the following fatal problem: When I build & run it on an iPhone (simulator or device) Xcode completes loading the app and then crashes too fast for me to copy/paste the error from the debugger. When I run on iPad it works fine leading me to believe this is a result of something related to the split master/detail view.
If I use either an exception breakpoint or an "all C++ exceptions" it will stop at the AppDelegate class and crash if I hit play. If I use only an "all Objective-C exceptions" it will crash as before.
In the debug view hierarchy I get the following errors as well:
Error: Unable to capture view hierarchy.
Details: Log Title: Data source expression execution failure.
Log Details: error evaluating expression “(id)
[[(Class)objc_getClass("DBGTargetHub") sharedHub]
performRequestWithRequestInBase64:#"...
Log Method: -[DBGDataSourceConnectionLibViewDebugger
_executeLLDBExpression:forRequest:onPotentialThread:iteration:]
_block_invoke_2
Method: -[DBGViewDebugger updateDebugHierarchy]_block_invoke_2
I have tested other apps and this issue is unique to the app I am working on. Any ideas or debugging tips for how to proceed? I might just have to redo this whole project again if I can't even find the root cause of this! Appreciate any help.
Quick solution: Reset Simulator Device
I managed to resolve the above issue thanks to some serious digging. First, to resolve the instantaneous crash problem, I set a breakpoint at every line in the app delegate. That allowed me to narrow the error to a memory handling problem. From there I started running the code on one of each device available, and realized the crash only occurred on devices I had used earlier in development. Resetting those devices solved the problem.
The core issue here is that when you clean/rebuild your xcode program, it updates the app code on the device, but not necessarily the data model information. So when I changed my data model by including new data and renaming old data it was not properly updated.
NOTE: I have seen many other posts on Stack Overflow about NSUserDefaults being renamed to UserDefaults in Swift or not working on simulator until a restart. This is not a duplicate by anyway. Many of the questions SO is tagging against is from 4 years ago. My question is specific to iOS 10 from this year as this has always worked in older versions. I have mentioned in my question already that my question is not a duplicate of those questions as those were simulator bugs in swift and my issue is on device objective C bug. Please read the questions before marking as duplicate
My issue is different as I am able to reproduce this on objective C and on physical device itself.
I created a brand new project from scratch for this test. I placed this code in the viewDidLoad of a view controller:
if (![[NSUserDefaults standardUserDefaults] valueForKey:#"checkIfInitialized"]){
NSLog(#"setting checkIfInitialized as not exist");
[[NSUserDefaults standardUserDefaults] setValue:#"test" forKey:#"checkIfInitialized"];
[[NSUserDefaults standardUserDefaults] synchronize];
self.view.backgroundColor=[UIColor redColor];
self.mylabel.text=#"NSUserDefaults was NOT there, try running again";
} else {
NSLog(#"checkIfInitialized exists already");
self.view.backgroundColor=[UIColor blueColor];
self.mylabel.text=#"NSUserDefaults was already there this time, try running again";
}
Now if I run the app about 10 times, few times it finds the checkIfInitialized and sometimes it doesn't. No exact number on how many times it fails as it might work 3 times then fail next 2 times then work 4 times and fail once and so on.
Now something I have noticed (not 100% sure though) that the issue only seems to happen when I am testing connected via Xcode. If I run by launching the app by clicking the app icon on device without Xcode, then it seems to work fine but I can't be 100% sure.
I noticed this error occur sometimes:
[User Defaults] Failed to write value for key checkIfInitialized in CFPrefsPlistSource<0x1700f7200> (Domain: com.xxxx.appname, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null)): Path not accessible, switching to read-only
I have this very simple project on my dropbox if you want to test it out.
I would suggest testing about 10-15 times to reproduce this issue.
https://www.dropbox.com/s/j7vbgl6e15s57ix/nsuserdefaultbug.zip?dl=0
This works completely fine on iOS 9 so definitely something to do with iOS 10.
EDIT
Bug logged: 28287988
Response from apple DTS team:
First off, you should first determine whether standardUserDefaults or
valueForKey is failing. My guess is that “standardUserDefaults” is
returning NULL and, if that’s the case, then that’s something you
should be guarding against generally. Notably, standardUserDefaults
will return NULL if the preference file is encrypted in the
environment the app is currently running in (for example, preferences
is set to “NSFileProtectionComplete” and the app is running in the
background). That shouldn’t be an issue for standard foreground-only
apps, but it’s something to be aware of anyway.
It’s very likely that Xcode is actually inducing the problem here.
Xcode vastly complicates the app launching environment in a way that’s
VERY different than a standard app launch. My guess is that this is
basically being triggered by Xcode’s timing inducing an an expected
situation during the app launch, but if you want a more formal test of
that try setting a single breakpoint in applicationDidFinishLaunching
and continuing in the debugger as soon as you hit it. My guess is
just adding that disrupts the timing enough to stop the problem from
happening. Sort of. It’s iOS 10 only in the sense that iOS 9 will
never print that log message, but that’s because the log message was
added in iOS 10. The code itself is similar enough to iOS 9.3 that I
suspect exactly the same behavior is (at least in theory) possible in
iOS 9.
Yes, this is definitely a reproducible bug.
It happens with the GM release of Xcode 8 and iOS 10.
It is not the linked question referring to Swift.
It is not the linked question referring to beta versions of the Simulator.
The bug happens on devices and on the Simulator. It is intermittent: saving will work six times and then fail. Unlike you, I did not get the "failed to write key" message.
The bug also occurs when operating directly on the device without Xcode. This is in fact how I discovered it.
You should report a bug to Apple, especially since you have a short program that will reproduce it. I will do the same.
One key difference: In my case the failure is in writing the default. The previously written value remains in NSUserDefaults. Sometimes one key is successfully written while another is unchanged.
A similarly very intelligent DTS response from my own support request. Basically, killing using Xcode is more murderous than anything that would naturally happen on the device (even the double-Home-click-and-upswipe method) and since everything is abruptly crashed when Xcode halts it, the lazy writing of NSUserDefaults can fail, or be only half completed.
And indeed, pure on-device testing of the app, without Xcode involved, shows that everything does get correctly written to NSUserDefaults when the app is terminated.
I have closed my own bug report.
I'm trying to diagnose my app with Address Sanitizer.
Although the app runs quite smoothly and I only wanted to get further checks regarding the memory alloc etc. I get the following error when I run the app.
It's my first time using Address Sanitizer but as far as I concerened it needs to point out to one of the developer's line of code.
It seems to me like it crashes at internal libary.
Any ideas or suggestions?
Apparently the problem was that I tried to run the game on an iPad with iOS8.0.
On iOS >= 9.0 it works fine.
I've got an app that crashes even before the debugger can connect.
I placed a break point on the first line of main(). (I added an NSLog statement as very first statement in main() and set the break point there.
The app seems to start. The main screen with some ui elements becomes visible on the screen. Then it disappears.
There is no crash log found on the devices.
Xcode message:
Could not launch "appname"
process launch failed: failed to get the task for process xyz
Debugging is enabled of course.
The same for the profiler Instruments.
Code signing works fine so that the app can be deployed to the devices.
(Same for enterprise distribution. And the app validates for store submission.)
It does work on the simulator though.
The app used to work fine. I was just about to build it for the store. For final tests on iOS 8.1 I upgraded to Xcode 6.1 with SDK 8.1. But the problem did not occur directly after the upgrade. It worked just fine.
Then it crashed when building for release for enterprise distribution.
The AppStore build crashed in the same manner (according to Apple, the app was rejected of course.)
But it ran nicely in debug modes.
Now I was trying whether compiler options for optimization may make all the difference and I was trying to build in release mode with debugging enabled etc and end up with a debug build crashing as well. (No optimization in debug).
So it may well be that the migration to Xcode 6.1 did cause it but the problem may have come effective only after Xcode cleaned and rebuild the project in response to changes to compiler settings for code optimization.
Sorry for the long text. I tried to put everything in that may be of importance.
Reason is most likely some incompatibility of Crackify and iOS 8.1.
Therefore it may be of interest for others, altough my problem along with these symptoms may be very special.
Very early within AppDelegate didFinishLaunchingWithOptions we have had the following statement.
if ([Crackify isCracked] || [self isCertificateUnvalid])
exit(173);
That, as such, is not really well designed. The app is just terminated rather than any error message displayed to the user. Thus, it appears as if the app has crashed. But it has not crashed and therefore no crashlog is provided.
For reasons which I don't yet understand and which may not be related to this error, my debugger did not manage to hook up into the executed app. Once that was overcome (suddenly the debugger worked without any changes made to any of the debugging related settings) the error was found rather quickly.
This is Crackify: https://github.com/itruf/crackify
Within Crackify it was this code sniplet that caused the problem:
static NSString *str2 = #"ResourceRules.plist";
BOOL fileExists3 = [manager fileExistsAtPath:([NSString stringWithFormat:#"%#/%#", bundlePath, str2])];
if (!fileExists3) {
return YES;
}
For reasons that I did not further investigate, the file, that is tested here, apparently does not exist in iOS 8.1 any more.