CouchbaseMobile startup failure on iOS 5.1

Jurgen-Lorenz Simon added a comment - 13/Mar/12 5:32 AM I would like to escalate this to a blocker.

Jens Alfke added a comment - 13/Mar/12 11:53 AM > the device must not have been enabled for development through Xcode. Is that permanent? Is there a way to reproduce this with a device that's already been development-enabled, short of wiping and re-installing the OS?

Tihomir Ivanov added a comment - 13/Mar/12 12:31 PM I have similar problem with an app that uses CouchBase on iOS 5.1. My app works when the device is connected to my development machine. All of the custom code was inspected and there are no memory leaks. The app crashes at start up only after I reboot the ios5.1 device and when the device is not connected to development machine. The app works just fine on ios5.0.0.1 and 4.3. ----------------------------------- Some details from the crash log: ----------------------------------- Incident Identifier: 0E3400D5-802F-4508-AD73-414E3CA608AB CrashReporter Key: c35154e21347780a3a93befed1dbd11b41b5a150 Hardware Model: iPad2,1 Process: halfteam [78] Path: /var/mobile/Applications/0F8E0ACA-D374-4673-AC46-B0811B6974D8/halfteam.app/halfteam Identifier: halfteam Version: ??? (???) Code Type: ARM (Native) Parent Process: launchd [1] Date/Time: 2012-03-13 11:24:39.012 -0400 OS Version: iPhone OS 5.1 (9B176) Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x00000000, 0x00000000 Crashed Thread: 0 Last Exception Backtrace: 0 CoreFoundation 0x33eb388f __exceptionPreprocess + 163 1 libobjc.A.dylib 0x329a5259 objc_exception_throw + 33 2 CoreFoundation 0x33eb3789 +[NSException raise:format:] + 1 3 Foundation 0x32df93a3 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 91 4 halfteam 0x000a4425 -[AppDelegate couchbaseMobile:failedToStart:] (AppDelegate.m:62) 5 halfteam 0x000cf2f9 -[CouchbaseMobile startupTimeout] + 89 6 Foundation 0x32e2b933 __NSFireDelayedPerform + 415 7 CoreFoundation 0x33e87a33 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 15 8 CoreFoundation 0x33e87699 __CFRunLoopDoTimer + 365 9 CoreFoundation 0x33e8626f __CFRunLoopRun + 1207 10 CoreFoundation 0x33e094a5 CFRunLoopRunSpecific + 301 11 CoreFoundation 0x33e0936d CFRunLoopRunInMode + 105 12 GraphicsServices 0x33387439 GSEventRunModal + 137 13 UIKit 0x35afee7d UIApplicationMain + 1081 14 halfteam 0x000a405f main (main.m:14) 15 halfteam 0x000a4018 start + 40 .....

Patrick Barry added a comment - 13/Mar/12 2:22 PM This appears to be happening to us as well ... and it's a *showstopper* for our app, obviously. CouchbaseMobile sometimes does not start up on launch when running on 5.1 ... same "Couchbase: Error: No startup notification from server engine" message ... our testing supports the idea that it works okay when connected to Xcode and the phone is enabled for development, and it seems to not work when not connected to Xcode. It doesn't seem to matter whether the debugger is running, though, because I've launched it *manually* while connected to Xcode (not by hitting the Run button in Xcode, so no debugger running) and Couchbase still failed to start. We were just about to submit to Apple for review! So, good thing we found this before the app was in the wild .. but it would obviously be good to get this fixed asap. Let me know if you need any other information to help debug it. Thanks!

Patrick Barry added a comment - 13/Mar/12 2:25 PM Oops .. let me edit one sentence in my last comment: "...because I've launched it *manually* while connected to Xcode (not by hitting the Run button in Xcode, so no debugger running) and Couchbase STARTED NORMALLY."

ewan mcdougall added a comment - 13/Mar/12 5:03 PM I can report a similar problem using couchbase mobile 2.0.1 on iOS 5.1 iPhone attached to development computer and run from Xcode, app runs as expected Mar 13 21:51:48 unknown miituu[90] <Warning>: Couchbase: Found db files in ~/Documents, so using that as rootDirectory Mar 13 21:51:48 unknown miituu[90] <Warning>: -[MiituuAppDelegate application:didFinishLaunchingWithOptions:] [Line 85] Documents Directory : /var/mobile/Applications/AE80CECD-22D3-42FD-8511-B885C028AC17/Documents Mar 13 21:51:48 unknown miituu[90] <Warning>: ------ applicationDidBecomeActive iPhone restarted and couchbase fails to start. Mar 13 21:52:18 unknown miituu[90] <Warning>: Couchbase: Error: No startup notification from server engine Mar 13 21:52:18 unknown miituu[90] <Warning>: -[MiituuAppDelegate couchbaseMobile:failedToStart:] [Line 264] OMG: Couchbase couldn't start! Exiting! Mar 13 21:52:18 unknown miituu[90] <Warning>: -[MiituuAppDelegate couchbaseMobile:failedToStart:] [Line 265] The operation couldn’t be completed. (Couchbase error 2.) : (null) Mar 13 21:52:18 unknown miituu[90] <Warning>: -[MiituuAppDelegate couchbaseMobile:failedToStart:] [Line 266] The operation couldn’t be completed. (Couchbase error 2.) : (null)

Patrick Barry added a comment - 13/Mar/12 5:11 PM Hi Jens. Could you give us a status on this bug when you have a chance? Just wondering if you all are working on it yet, and if you have any sense yet of whether it's going to be a relatively quick fix. We're under some pressure to launch asap (investors and such), so it would be good to have some sort of estimate of how long it might be, if at all possible. Thanks again!

Chaise Hocking added a comment - 13/Mar/12 5:24 PM >Is that permanent? Is there a way to reproduce this with a device that's already been development-enabled, short of wiping and re-installing the OS? Hi Jens, Yes it is permanent. Though it is relatively fast to reset the device without needing to re-install the os. If you use: >Settings >Reset >Erase All Content and Settings This will cause couchbase to consistently and repeatedly fail. So far I have not been able to reproduce the issue the issue once the device has been "enabled for development". Using "Use For Development" will enable a previous install of the same app to begin working.

Jens Alfke added a comment - 13/Mar/12 5:29 PM The problem appears to stem from Erlang calling printf. As far as I can tell, this is hanging — maybe because stdout isn't attached to anything and locks up when its buffer fills up? All I know is that, if I use freopen to redirect stdout to a file, it makes the problem go away. I'm asking on Apple's mailing lists to see if anyone knows anything about this issue. But the good news is that I can check in a two-line patch that makes it go away (even if I don't know exactly why.) > Yes it is permanent. Really? I was able to reproduce it simply by shutting down and restarting the device. After that, the app will lock up, until the next time the device is tethered to Xcode.

Patrick Barry added a comment - 13/Mar/12 5:38 PM That's great news Jens! Looking forward to trying out the fix. Are you going to post a new binary of couchbase mobile as well as checking in the patch? Compiling CBM from source was a bit tricky, as I recall.

Jens Alfke added a comment - 13/Mar/12 5:50 PM Out for review: http://review.couchbase.org/#change,13924

Jens Alfke added a comment - 13/Mar/12 5:51 PM Patrick: Yes, we will post a new build. Hopefully later today or tomorrow.

Patrick Barry added a comment - 13/Mar/12 6:17 PM Thank you so much Jens! You're like Superman flying in and saving the day! :-) So will the new binary be on the CBM wiki page? Is there a way to be notified when it's available?

Chaise Hocking added a comment - 13/Mar/12 7:37 PM For anyone who cannot wait for a new Couchbase mobile build, there is no reason why you can't put Jens's fix in your own application code. NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); NSString *logDirectory = [[paths objectAtIndex:0] stringByAppendingPathComponent:@"Logs"]; if(![[NSFileManager defaultManager] fileExistsAtPath:logDirectory isDirectory:NULL]) [[NSFileManager defaultManager] createDirectoryAtPath:logDirectory withIntermediateDirectories:YES attributes:nil error:NULL]; freopen([[logDirectory stringByAppendingPathComponent:@"stdout.log"] UTF8String], "w+", stdout);

Jens Alfke added a comment - 13/Mar/12 8:13 PM Actually you could do an even simpler fix if you don't care about stdout at all:     freopen("/dev/null", "w", stdout); I'm finding that some other developers are running into this issue too, although I haven't found anyone who knows exactly what's going on: http://bugs.freepascal.org/view.php?id=21440 http://blog.xamarin.com/2012/03/11/monotouch-and-ios-5-1/

Tihomir Ivanov added a comment - 13/Mar/12 8:37 PM Thanks, Chaise -- The proposed solution worked for me. Our app was approved a week ago and we are about to go live so this was a truly urgent issue... Highly appreciated!