The following bug report has already been confirmed by Apple. Still I am posting it for the public so that it might help somebody who is getting the same problem.
The workaround is to override the readFromURL:error: method of UIDocument instead loadFromContents:ofType:error: since the problem lies inside NSFileWrapper. While being very convenient to use on smaller documents having too many items inside an NSFileWrapper will cause the problem described in this bug report.
Filed as rdar://13586175 and on Open Radar.
Summary
Frequent opening and closing of a UIDocument subclass (not using iCloud) leads to a silent termination of the app.
Steps to Reproduce:
- have UIDocuments with hundreds of images in them
- open these UIDocuments and close them several times until the app is just gone
Expected Results
The app should not be terminated with signal 9. In the least a useful crash report should be created.
Actual Results
App is killed with signal 9, on the console this output is logged:
Apr 5 15:47:22 Stefan-Gugarels-iPad iCatalogTest[2700] <Error>: shared connection error: Connection interrupted Apr 5 15:47:22 Stefan-Gugarels-iPad com.apple.launchd[1] (com.apple.librariand[2672]) <Notice>: (com.apple.librariand) Exited: Killed: 9 Apr 5 15:47:23 Stefan-Gugarels-iPad com.apple.launchd[1] (com.apple.tccd[2681]) <Notice>: (com.apple.tccd) Exited: Killed: 9 Apr 5 15:47:23 Stefan-Gugarels-iPad com.apple.launchd[1] (UIKitApplication:com.int-color.icatalogtest[0x114b][2700]) <Notice>: (UIKitApplication:com.int-color.icatalogtest[0x114b]) Exited: Killed: 9 Apr 5 15:47:23 Stefan-Gugarels-iPad com.apple.debugserver-199[2698] <Warning>: 1 +0.000000 sec [0a8a/1303]: error: ::read ( 5, 0x1c89fc, 18446744069414585344 ) => -1 err = Bad file descriptor (0x00000009) Apr 5 15:47:23 Stefan-Gugarels-iPad backboardd[26] <Warning>: Application 'UIKitApplication:com.int-color.icatalogtest[0x114b]' exited abnormally with signal 9: Killed: 9 Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: vnode: table is full Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: vnode: table is full Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: vnode: table is full Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: vnode: table is full Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage
We suspect that this is a bug in the iOS SDK.
Regression
The problem started to occur when we switched to a UIDocument-based subclass for our document.
Notes
I am using multiple UIDocuments for displaying Catalogs. I open UIDocuments show them and close them. I am repeating the previous step until the app is killed with signal 9. (But i get no Crashlog and no Exception during Debugging). The only hint for me is found in iPad Console of device.
We verified that the UIDocument is being deallocated after showing. We are not using file presentation, but only the asynchronous loading facilities of UIDocument. We are not using iCloud and we do not need to save the UIDocument.
The out of vnodes condition seems to be related to using the NSFileWrapperReadingImmediate reading option of NSFileWrapper since we are able to show the termination both with an explicitly created file wrapper with this option as well as UIDocument. UIDocument appears to be using the same file wrapper reading option internally.
If we change the reading option to NSFileWrapperReadingWithoutMapping then the problem no longer occurs.
Even if this is “by design” then in the least we would expect for a useful exception to be raised such that an unsuspecting developer would have a clue how to work around that.
Categories: Bug Reports
