Application Driven to Crash Only F… | Apple Developer Forums

Developer Forums

Has anybody seen a case where

the application is driven to crash when the user launches it for the first time and then resizes its window and
the same thing never happens once they quit the application

What I'm looking at is application's relation to plist file inside its savedState folder. When the application starts up for the first time, the system creates a new folder in Library > Saved Application State. If the bundle ID is net.Joe.Hello, its folder name should be net.Joe.Hello.savedState. And there is a file titled windows.plist. My application doesn't have the restorable switch on. So there is no reason for it to write to this file and store window's frame data except that it seems that it is. I'm not certain at all, but my applications are driven to crash after trying to access this file.

I have already opened a DTS ticket. All I can I say is that he isn't very helpful.

Thank you for any tips.

AppKit

4.4k

Posted by

Tomato

Reply

Accepted Reply

>> It doesn't crash while the application is running with th debugger.

If you are starting the app by running it in Xcode, you can edit the scheme options, and check the "Persistent State: Launch application without state restoration" option to run the app as if it had just been installed. If the crash is timing dependent, this may still not trigger it, but it's worth a try.

>>If you actually have a crash log, it should be relatively easy to find out.

What I meant was, if there's a crash log, you can post parts of it here and we'll try to help you interpret it. The important parts to post (initially) are the entire section at the top above the first thread backtrace, and the backtrace (up to about 20 lines) of the thread that crashed. You can redact private details like app names, etc, when posting.

The important question here is whether the unwrapped nil is happening in your code, or in system/frameworks code. If it's the latter, there's probably nothing you can do about it, other than submit a bug report. However, it's possible that understanding the backtrace may lead to a workaround.

Posted by

QuinceyMorris

Replies

>> My application doesn't have the restorable switch on.

What switch is that?

Note that even if you don't opt into state restoration for the things you control, the Cocoa frameworks may still have state to save for private reasons.

What is your app doing when it crashes? (What does the backtrace show?) Does it crash due to an exception, or something else?

Posted by

QuinceyMorris

Could be that you have a plist which is not completely defined at first launch.

When you get values from those plist, do you always do it with an optional binding or ?? operator ?

Posted by

Claude31

>What switch is that?

I'm referring to NSWindow's Restorable.

>Note that even if you don't opt into state restoration for the things you control, the Cocoa frameworks may still have state to save for private reasons.

That's the very reason why I'm asking this question.

>What is your app doing when it crashes? (What does the backtrace show?) Does it crash due to an exception, or something else?

When the user resizes the window, the application will eventually crash. When it does, a crash report says "Fatal error: Unexpectedly found nil while unwrapping an Optional value" except that there is no unwrapping involved. You can tell that the application has crashed even when it hasn't terminated itself. The application will become unresponsive. Its menu commands get corrupted. And it will, again, crash eventually.

Posted by

Tomato

>Could be that you have a plist which is not completely defined at first launch.

I don't know. I don't access it. That's why I'm asking this question.

>When you get values from those plist, do you always do it with an optional binding or ?? operator ?

I don't access them at all. Just as Quincy suggests, the application seems to do it on its own when the user launches it for the first time. I don't have the restorable switch on. I don't use UserDefaults. I didn't even know windows.plist existed till recently. I don't access any of the guys in the saved application State folder.

Posted by

Tomato

There's nothing wrong or suspicious if some state is being saved to a private location.

The real question is where it crashes. If the app crashes when you run it from Xcode, it should stop in the debugger at the point of the error. Otherwise, you can find out where it crashes from the crash log.

"Where", in this case, means "in what method". If you actually have a crash log, it should be relatively easy to find out.

Posted by

QuinceyMorris

>If the app crashes when you run it from Xcode, it should stop in the debugger at the point of the error. Otherwise, you can find out where it crashes from the crash log.

It doesn't crash while the application is running with th debugger.

>If you actually have a crash log, it should be relatively easy to find out.

I don't think so.

Posted by

Tomato

>> It doesn't crash while the application is running with th debugger.

If you are starting the app by running it in Xcode, you can edit the scheme options, and check the "Persistent State: Launch application without state restoration" option to run the app as if it had just been installed. If the crash is timing dependent, this may still not trigger it, but it's worth a try.

>>If you actually have a crash log, it should be relatively easy to find out.

What I meant was, if there's a crash log, you can post parts of it here and we'll try to help you interpret it. The important parts to post (initially) are the entire section at the top above the first thread backtrace, and the backtrace (up to about 20 lines) of the thread that crashed. You can redact private details like app names, etc, when posting.

The important question here is whether the unwrapped nil is happening in your code, or in system/frameworks code. If it's the latter, there's probably nothing you can do about it, other than submit a bug report. However, it's possible that understanding the backtrace may lead to a workaround.

Posted by

QuinceyMorris

>If you are starting the app by running it in Xcode, you can edit the scheme options, and check the "Persistent State: Launch application without state restoration" option to run the app as if it had just been installed. If the crash is timing dependent, this may still not trigger it, but it's worth a try.

I think this is it. That's something that I have never heard of. Yooo Hoo! I have to test it. Thanks.

Posted by

Tomato

I think you have solved the case. It's been a two-year-long journey, which my DTS guy has abandoned it. I wish I could buy you a beer. I'm so happy. Life can't be any better. THANK YOU!

Posted by

Tomato

Interesting : If you are starting the app by running it in Xcode, you can edit the scheme options, and check the "Persistent State: Launch application without state restoration"

But I've not found the option in XCode 9. Where is it ?

Posted by

Claude31

1. Choose Manage Schemes under Product > Scheme.

2. Double-click on a scheme.

3. Select Run.

4. Navigate to Options. And you find it there.

Posted by

Tomato

That's what I did (in fact direct aceess to scheme edit for the app by clicking on the left of the present scheme).

But, in XCode 9.4, no such "Launch application without state restoration" option.

Posted by

Claude31

It’s only there for macOS targets. We’re you looking at an iOS app?

Posted by

QuinceyMorris

You're right, once again.

Posted by

Claude31

Actually, now that iOS has state restoration, it seems like it ought to be offered for iOS apps too. My guess that this scheme option is based on an environment variable that could be set manually instead, but I don't know what it is.

Posted by

QuinceyMorris