GSRegisterPurpleNamedPort SIGABRT in UIApplicationMain Before App Delegate Gets to Run Any Code - iphone

We recently put an update out for one of our apps and many users told us that they could no longer run the app because it crashed on startup.
We have been able to recreate the crash by building and running the previous release build onto a device and then building and running the new build overtop of it on the same device, but the stack trace for this crash is very strange:
Thread 0 Crashed:
0 libSystem.B.dylib 0x000791d0 __kill + 8
1 libSystem.B.dylib 0x000791c0 kill + 4
2 libSystem.B.dylib 0x000791b2 raise + 10
3 libSystem.B.dylib 0x0008d6fa abort + 50
4 GraphicsServices 0x00003aa8 GSRegisterPurpleNamedPort + 172
5 GraphicsServices 0x00003d5a GSEventInitialize + 150
6 UIKit 0x00004cd6 UIApplicationMain + 350
7 MyApp 0x0000df5c main (main.m:14)
8 MyApp 0x00002c84 start + 32
It appears to be crashing in the UIApplicationMain method that main calls. But it crashes before it reaches any of the methods in our app delegate. I have put breakpoints in all of the app delegate methods and none of them are reached.
In addition, this appears to be only occurring for users that are updating the app. Users that are downloading it from the app store without it already being on their iPhones are not seeing the problem.
Has anyone ever encountered a crash like this? Why would this problem only occur for updates?

Is this under iOS 4.0? This type of error had been reported to occur when a process or thread from the previous install of this app has crashed and somehow hasn't been cleaned up by the OS yet or has hung up in the debugger.
Does a reboot of the iPhone after installation of the new version of the app cause this error to go away? That would be one good indication that something is stuck/corrupted in the OS from the previous install, rather than in the app bundle itself.

I've been having the same issue (thankfully I caught it before submitting to the AppStore). Unlike this answer states, the issue still occurs on iOS 5.x and 6.x.
So I went into the Console and found a few messages were logged before my app crashed. First was this message:
com.apple.launchd.peruser.503[148]: (UIKitApplication:BUNDLE-ID[0x4fb5][20462]) The following job tried to hijack the service "BUNDLE-ID-1" from this job: UIKitApplication:BUNDLE-ID-1[0xac31]
The next message in the console displays immediately afterwards:
GSRegisterPurpleNamedPort Couldn't register BUNDLE ID with the bootstrap server. Error: unknown error code (1100).
This generally means that another instance of this process was already running or is hung in the debugger.
The crash is caused by another almost identical process already running on the system. It sounds like an issue with iOS not the app itself. This should help clear things up. Best thing to do would probably be to tell users to quit the app, try restarting and open again.
I've also submitted a bug report to Apple detailing the issue.
EDIT: It looks as though this might have been an issue with Xcode itself. Apple has just released an update which should fix the issue (at least in the Simulator):

I got this problem in a project every time i debugged it a second time. Only rebooting the device would allow me to debug once again.
This particular cause of the above stacktrace was finally solved by reinstalling iTunes.

It might be purely co incidence but when ever i debug the application release mode and than without deleting it again tries to debug it in debug mode this problem seems to happen. restarting it however does the trick .

It seems that old app has been launched without quit completely, some handlers is still alive or registered by OS, so when you launch the new version, app crash.
I have also experienced such tough issue, how do you fix it finally? Thanks.

No core data here. Just updated a text file in the main bundle, and all of a sudden this
"purple point" fail. IOS 5.1.1, iPad, opengl app with a lot of gestural interfacing.
I was real glad to find some clues here. The reset fixed it.

It seems that happend also to me when update to 10.8.4, I guess it is an Xcode bug, I will issue a bug report. If the app is opened and I run it from Xcode, the app crashes, soetimes it restarts by itself and sometimes I need to relaunch it again.

If you use Core Data in your app and changed the schema, then you will often see this issue arise. What happens is the old version of the app will have an old version of the database (sqlite presumably) and when the new version of the app starts up, it expects the new version of the database as well. This causes a crash right at startup like this.
The immediate fix for this is to delete the app and re-install it. We do this while in development. But when you are ready to push the new version, you'll need to setup a Mapping Model in order to migrate your database. There is a lot of info on data migration in the developer docs:
http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/CoreDataVersioning/Introduction/Introduction.html

Related

How to fix "Read-Write-Data Sandbox: error when using Mac Catalyst

I recently updated to macOS Catalina so I could update some of my apps with Mac support using Catalyst. Whenever I run the app and it tries to access the CloudKit data (I use CloudKit to sync Core Data, Data if an iCloud Account is available), it then crashes with the following error. [User Defaults] Couldn't write values for keys ( ApplicationAccessibilityEnabled ) in CFPrefsPlistSource<0x600002c07700> (Domain: com.apple.Accessibility, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access
I have tried changing Permissions and Access in App SandBox settings in my Signing and Capabilities, to read/write. I have also tried changing incoming and outgoing connections to on.
I am not exactly sure what code I should show so here is the area is crashes in.
if isICloudContainerAvailable() {
print("iCloud Available")
let container = NSPersistentCloudKitContainer(name: "Shopping_App")
container.loadPersistentStores(completionHandler: {
(storeDescription, error) in
if let error = error as NSError? {
fatalError("Unresolved error \(error), \(error.userInfo)")
}
})
return container
}
I except the app to create/get the CoreData data and if available (which is in this case) to connect to the CloudKit synced data. But it crashes right now before it even brings up any views which leads me to think that it is crashing in the AppDeleget somewhere.
Update Oct. 14 -- I found that if I force Jump Over the Breakpoint where the app crashes, I can continue into the app and it works fine. Which leads me to think that the error is really in the AppDeleget especially saying that the UI does not appear until after I jump over the breakpoint it sets at the crash.
Update Nov. 4 -- So this problem gets even stranger. I forgot I was using a beta version of Xcode, so ok, it could have just been that after I realized that last week. I tried running the app through the public version and the app never stopped for a breakpoint but instead completely crashes with Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0). This error is just really odd. Would this be an error that I should report to Apple? I thought about doing that but I decided not to because it seemed to me like something I could have been doing, but now rethinking whether I should or not. I wish I could find the solution to this problem because I would like to release the macOS version to the public, but have not had any luck finding a solution.
Update Nov. 8 -- In Xcode 11.2.1 GM seed the problem still persists. I have yet to find the exact reason this problem occurs but will continue to try. I have also been unable to reproduce the error written in the update on Nov. 4, on any Xcode version. I have not found anything else but wanted to update this with information about the GM seed and if this still happens.
Update Nov. 13 -- I decided to just go ahead and upload the app to Apple for approval since building the app and running it independently from Xcode worked just fine. Apple approved the app without any complaints of this issue. This just seems to be an Xcode issue. I will continue to update this however and if/when I find a solution I will post the solution to this problem but have not found anything more to workaround or solve this problem.
Update Nov. 20 -- On Xcode 11.3 Beta Build 11C24b, the problem still occurs. Nothing else has changed and I have not found anything else to solve this problem. I will continue to keep this updated but have not found anything else yet.
Update Dec. 11 -- On Xcode 11.3 Public 11C29 the problem still continues. However, now it is not consistent and sometimes I have to go over the breakpoint twice instead of just once for the application to continue launching. It still does not occur though if ran independently from Xcode.
Update Jan. 2, 2020 -- Still occurs but now verified that it occurs on a real iOS 13 device. No other solutions or stepovers found though. I will continue to update this post however with any other information.
Update Feb. 17, 2020 -- Not much of an update but still occurring on Xcode 11.4 Beta (11N111s). Will continue updating this post however not much has changed. (Fixed some misstakes on this post as well)
Update March 10, 2020 -- I did not realize that Xcode beta 11N132i was released but after testing it still occurs. However, though it may still be occurring, it is at least less consistent. Now instead of it happening and doing this every time, it appears to be somewhat random.
Update April 18, 2020 -- Sorry for not updating this post, I have been unable to program until now. I still have not figured out this issue but it seems that now it is not really happening. It still happens just rarely now. This also is on Xcode 11.4.1 (11E503a), and I am not sure why still. I will continue to try and update this post. Thank you. If you have any suggestions to try to find the cause, I am open to hearing them.
Update May 14, 2020 -- Xcode 11.5 Beta 2 (11N605f) This problem still occurs randomly, but now it seems to not always include the error yet still points to that portion of code. Thank you for your support of this post, and I will continue updating it as I find more about this problem.
Update Jun 5, 2020 -- I am sorry for not updating this any sooner, I completely forgot when I had updated Xcode. On Xcode 11.5 this problem still persists like it has been. I have also updated to Catalina 10.15.5 and have seen little to no changes. However, like the comments have said, Catalina 10.15.4 did help this has I heard, but 10.15.5 seemed to not change anything, which is strange.
Update Jun 27, 2020, and July 22, 2020, and Aug 10, 2020 -- I have updated my project to now support Xcode 12 and it appears to still have the same issue. Nothing has really changed and the log is the exact same. I appeaciate everyone willing to contiune in helpin fix this issue as well. This is also the same on Xcode 12 Beta 2. The excat same for betas 3 and 4.
Update Sep 28, 2020 -- This is still an issue on the GM and Public versions of Xcode 12. I have not updated to Xcode 12.0.1 because I am waiting for macOS Big Sur, but at this point, I doubt that would solve it. I really do not have any updates, other then it still is occurring and I cannot find the issue.
Update Nov 3, 2020 -- This still appears to be an issue on Xcode 12.1.1 Release Candidate. Sorry for not updating this for so long, I was holding out updating Xcode as I previously stated, but I decided to go ahead and update. However, updating to the Release Candidate has not changed anything, or not at least that I can notice. One change I did notice; however, was that it seemed to show this issue sooner, but that could just be that it compiles it quicker. To summarize, no major changes to this problem and nothing has really changed with it in a while.
UPDATE Nov 16, 2020
I have since updated to macOS Big Sur 11.0.1 and updated Xcode to 12.3 beta. The problem still seems to occur after having to change a few random things to get it working on Big Sur. However, most everything I changed I think is unrelated because it was mostly related to the UI elements. This may just be Big Sur but it compiles much faster, and the error now shows much quicker; however it still is the same error.
MasterChief96, you are not alone. Here is my setup:
MacOS 10.15.3
Xcode 11.4.1
I create a brand new SwiftUI "Hello World" project, enable Mac as a target device, a.k.a. Catalyst.
I set the iOS deployment target to 13.2 (otherwise I get a MacOS runtime error saying I need Catalina 10.15.4)
Set the scheme to "My Mac", compile and run and get:
[User Defaults] Couldn't write values for keys
ApplicationAccessibilityEnabled
AccessibilityEnabled
FullKeyboardAccessFocusRingEnabled
setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access
Since it refers to the sandbox, I change the "Signing and Capabilities" setting for App Sandbox to include Read/Write for User Selected and Downloads File Access.
I quite Xcode, delete the project's Derived Data, open the project and run. The error messages persist when running on MacOS. (I do not see the messages when running on iOS.)
Just guessing here, but this appears to be yet another bug in the Catalyst environment? Maybe this bug is fixed in Catalina 10.15.4 but that update was such a disaster for me I had to back port to 10.15.3.
For me, I was getting this exact error message but the crash was happening due to the next error message where it was referring to missing CFBundleName in the Info.plist for my Mac Catalyst app.
The snippet of stack trace:
(Domain: com.apple.Accessibility, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access
2020-06-27 11:01:52.403837-0700 Manga Relay D[17329:517025] [General] An uncaught exception was raised
2020-06-27 11:01:52.403908-0700 Manga Relay D[17329:517025] [General] *** -[__NSDictionaryM setObject:forKey:]: object cannot be nil (key: title)
2020-06-27 11:01:52.404006-0700 Manga Relay D[17329:517025] [General] (
0 CoreFoundation 0x00007fff2eb82be7 __exceptionPreprocess + 250
1 libobjc.A.dylib 0x00007fff6795a5bf objc_exception_throw + 48
2 CoreFoundation 0x00007fff2ec3160e -[__NSCFString characterAtIndex:].cold.1 + 0
3 CoreFoundation 0x00007fff2ec3c17c -[__NSDictionaryM setObject:forKey:].cold.3 + 0
4 CoreFoundation 0x00007fff2eac0329 -[__NSDictionaryM setObject:forKey:] + 976
5 UIKitCore 0x00007fff6f5f2c8f -[_UIMenuBarItem properties] + 99
6 UIKitMacHelper 0x00007fff5fd6272a UINSNSMenuItemFromUINSMenuItem + 90
...
Once I specified a name in the "Bundle name"(aka CFBundleName), the crash went away but I still do get the error message about setting preferences outside an application's container.
Update with more details: The following screenshot of my Info.plist is defining the CFBundleName as my user-defined variable like $(MangaRelayBundleDisplayName) and I found out I never defined this anywhere, so it was nil which was causing the crash. When I entered the value such as "My App", the crash went away. Now, this solution has nothing to do with the original question, and basically I was mislead by the "sandbox access" warning, but I figured there could be other people who are being mislead by the warning.
I am on macOS 10.5.5 and Xcode 11.5.
I had the same problem.
Solved by deleting the "All runtime Issue" breakpoint.
After tests,
Thread Satanizer (Runtime Issue) works fine
Undefined Behavior (Runtime Issue) works fine
Main Thread Checker (Runtime Issue) works fine
System Frameworks (Runtime Issue) BREAK

GSRegisterPurpleNamedPort SIGABRT crash, reboot the device can fix this issue, however I want to find the root cause

The same issue as the following thread, reboot the device can fix this issue, however I want to find the root cause, user upgrades our app, we can't expect them to reoot the device to use it normally.
It will always occur by the following steps.
User launch app with version 1.1.
User put app into background (still running).
User upgrade app to new version 1.2.
User click app icon, app crash during startup.
Any idea or discussion will be apprecicated, thanks in advance.
GSRegisterPurpleNamedPort SIGABRT in UIApplicationMain Before App Delegate Gets to Run Any Code
App is crashed before new version app installed, some system clean action hasn't been done.

iPhone Project Not Running (more than once)

I have an iPhone app that I'm trying to run on my phone via Xcode.
It installs and runs without an issue
I make a change in the source code (negligible, like an NSLog())
It installs without an issue
Running causes the error:
Error Starting Executable 'myApp'
Don't know how to run. Try "help target".
I uninstall the app, and reboot the phone
It installs and runs without an issue (until I make another change; then I have to repeat this dance)
Needless to say, having to uninstall the app, reboot the phone, and reinitialize the environment (i.e. set prefs) takes an unreasonable amount of time, and is probably indicative of a serious problem. The issue is, the only vague error message I receive gets me nowhere on Google. Where on earth could this issue be coming from?
With some help from #iphonedev, I figured it out. Turns out it's a glitch in iOS 5 beta. The way to fix it is to remove the device from Development Devices, then re-add it.
Yeah just restarting the iPhone with the lock and home buttons fixes this. Had it happen a few times to me

What can cause unreported crashes for an iphone app?

I have an app that I occasionally receive support emails for that say the app crashed on them and won't open up anymore. It shows 'Default.png' then exits. Even when the app is deleted and reinstalled.
-I get no crash reports or memory issues (as reported by itunes connect using reports from a significant sample size >20k downloads)
-I've confirmed it's not limited to a specific model and not caused by jailbroken devices.
-The app doesn't have external dependencies, so why would reinstalling it not fix the problem?
What kind of problems could cause the crashing to go unreported and be persistent?
If you have an uncaught exception handler, depending on what you have in there, you will not get reports written out the same way, or at all, as if you did not have a handler. This will make iTunes think there is not any crash reports at all. Uncaught exception handlers are commonly added as part of analytics frameworks, or third party notification tools.
While this could answer your question, a more reasonable explanation is that the crashing devices just need a device restart.
I think every app developer with a sizable install base has struggled with an issue like this in the past.
Are you using any sort of analytics package, such as Flurry, that helps you report crashes? We used Flurry with much greater success over Apple - Apple won't start reporting crashes to you until you have many -- and "just a few" is never enough.
Additionally, if it shows the default.png and crashes, take a hard look at your start-up code. Are you setting something in NSUserDefaults, that if, corrupted, could cause the app to crash on startup?
Admittedly it is strange that a delete-and-reinstall doesn't do the trick.
The users aren't reporting the error reports to Apple. The crashes could come from any number of sources.
You could walk a user through the process of digging crash reports directly out of iTunes during the next Sync and email them directly to you.
You could try asking a user to delete the app from the device, reboot their device, then have them install the app again after a fresh reboot.

What does that mean? "mi_cmd_stack_list_frames: Not enough frames in stack."

Debugger is telling me this, when I run my app on device:
Program received signal: “EXC_BAD_ACCESS”.
mi_cmd_stack_list_frames: Not enough frames in stack.
mi_cmd_stack_list_frames: Not enough frames in stack.
I don't get information about where in code that happens. That's all I get. Any idea what that could mean?
The app crashes after that. When the device is not connected to the mac, it still crashes, so not a debugger problem.
Building on the 4.0 sdk onto a 3.1.3 phone caused this for me.
Fixed by weak linking UIKit in the target.
EXC_BAD_ACCESS happens when a message is sent to an object that has already been released.
I've seen "mi_cmd_stack_list_frames: Not enough frames in stack" before when trying to release something that's already been released as well.
My suggestion is to set the NSZombieEnabled environment variable and see which released object you are trying to access.
This site has a great tutorial on it:
http://www.codza.com/how-to-debug-exc_bad_access-on-iphone
I've seen this caused by at least three different kinds of problems:
• As described in the other answer, overrelease errors can do it.
• I had it happen when I was upgrading an app to use iAd and IOS 4.0. I think the problem was that I tried to use the iAd framework in the 3.0 version of the app as well, which of course isn't possible because iAd is only around in 4.0 and above.
• I had it happen when I removed a bunch of stuff from an app and recompiled, but vestiges of the old stuff were still around on the simulator. Resetting the simulator cleared the problem. What I was removing was the Flurry API. I'm afraid I don't know what, specifically, in there stuck around and caused the problem.
I have the same issue. My solution is:Quit the Xcode and then restart it after waiting some time.
I've got such a message when was trying to launch an app on iPhone under iOS 3.1.2 with a string like that
Class messageClass = (NSClassFromString(#"MFMessageComposeViewController"));
At the same time that works well when I use a device with iOS 4.
So I can assume that app could crash when start running on device if there are any references to iOS4-only classes.
Creating a new project and copying all the existing files in it solved this problem for me.