Failed to generate newParagraphStyle failure

Question

Various crashes appear in my reports that report the following reason:

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'failed to generate newParagraphStyle' 

The application in which this happens installs the program code of the attached text (fonts, colors, sometimes paragraph styles), but I cannot find any template directly related to this. What I see, almost all reports include a link in the stack trace in some form of setLineBreakMode:

 -[_UICascadingTextStorage(Accessors) setLineBreakMode:] 

I could never recreate this myself, but it appears on a regular basis in my crash report. I do not set the line break mode in any of these places. Any ideas?

EDIT: I spent more time on this and was able to find a sample to play. Thus, I have a UITextField, and when you press return on the keyboard, the character "/ n" is detected, and the text field resets the status of the first responder. If at any time after that you try to change the text (or text attribute) of the field, it will work. There is one key element, this only happens if you type a set of attributes. It does not matter what they are installed for.

I tried everything by setting typingAttributes to nil before setting the text, setting a fixed line to make sure that this is not what we set for it - no luck. Saves a crash. It seems as soon as you get into this state, the text box is simply broken. Hacking to avoid this is to blow away the text box and create a new one, but it is. Breaking.

Another interesting piece of information: the method for detecting the return code was not well written - it detected "/ n" and returned NO in:

 - (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string 

He did not use the appropriate method:

 - (BOOL)textFieldShouldReturn:(UITextField *)textField 

In one place of the application, this actually fixed a failure, in other places he always used the correct method, and the accident still occurs. The only work around is to blow away the text box and create a new one. For me, this seems like a bug in iOS itself.

Answer 1

I had this problem just now, and I was able to fix it by setting the typingAttributes problem textField to nil just before resignFirstResponder is called by the same textField .

Answer 2

Frankie's solution helped, but still found edge cases that caused this error:

 ** Assertion failure in -[_UICascadingTextStorage setLineBreakMode:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKit_Sim/UIKit-3512.30.14/TextSystem/_UICascadingTextStorage.m:292 

My solution was to subclass UITextField and add the hackTextAttributes property:

 import UIKit class HackTF: UITextField { var hackTextAttributes: [String: AnyObject] init(frame: CGRect, textAttributes: [String: AnyObject]) { hackTextAttributes = textAttributes super.init(frame: frame) delegate = self } required init?(coder aDecoder: NSCoder) { fatalError("init(coder:) has not been implemented") } func hackSetText(text: String) { attributedText = NSAttributedString(string: text, attributes: hackTextAttributes) } func hackSetAttributedText(text: String, attributes: [String: AnyObject]) { hackTextAttributes = attributes hackSetText(text) } } extension HackTF: UITextFieldDelegate { func textFieldDidBeginEditing(textField: UITextField) { typingAttributes = hackTextAttributes // Make sure fields with no text have appropriate typingAttributes } } // MARK: Apple Crash Prevention Hack extension HackTF { override func resignFirstResponder() -> Bool { var isResigningHack = false if self.text?.length == 0 { // if no text, add some text so we won't crash... isResigningHack = true attributedText = NSAttributedString(string: " ", attributes: hackTextAttributes) } typingAttributes = nil let resign = super.resignFirstResponder() if isResigningHack { // clear the text attributedText = NSAttributedString(string: "", attributes: hackTextAttributes) } return resign } }