[MOD-2396] iOS: Ti.Identity - Crashes about 20% of the time

GitHub Issue	n/a
Type	Bug
Priority	High
Status	Resolved
Resolution	Cannot Reproduce
Resolution Date	2018-07-23T10:22:56.000+0000
Affected Version/s	n/a
Fix Version/s	n/a
Components	TouchID
Labels	n/a
Reporter	Hans Knöchel
Assignee	Vijay Singh
Created	2018-01-29T10:12:56.000+0000
Updated	2018-07-23T10:22:56.000+0000

Description

(Moved from [Github](https://github.com/appcelerator-modules/titanium-identity/issues/8)) There seems to be a stability issue with the module on iOS. We are testing this for one of Axway's enterprise clients, and about 20% of the time it crashes the entire app after processing a user's Face ID. We are on the latest everything...AppC 7.0, etc... Here are some details of the crashes: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Thread 13 Crashed: 0 libobjc.A.dylib 0x00000001807a81a0 objc_retain + 16 1 Jason's Deli 0x0000000102a24568 0x102544000 + 5113192 2 libdispatch.dylib 0x0000000180ec1088 _dispatch_call_block_and_release + 24 3 libdispatch.dylib 0x0000000180ec1048 _dispatch_client_callout + 16 4 libdispatch.dylib 0x0000000180efc4e0 _dispatch_queue_override_invoke$VARIANT$armv81 + 700 5 libdispatch.dylib 0x0000000180f02418 _dispatch_root_queue_drain + 564 6 libdispatch.dylib 0x0000000180f02180 _dispatch_worker_thread3 + 112 7 libsystem_pthread.dylib 0x0000000181167120 _pthread_wqthread + 1268 8 libsystem_pthread.dylib 0x0000000181166c20 start_wqthread + 4 ---------------------------------------------------------------------------- Exception Type: EXC_BAD_ACCESS (SIGSEGV) Thread 12 Crashed: 0 JavaScriptCore 0x0000000187f0cf98 JSC::speculationFromStructure+ 659352 (JSC::Structure*) + 0 1 JavaScriptCore 0x0000000188114d4c JSC::CodeBlock::updateAllPredictionsAndCountLiveness+ 2788684 (unsigned int&, unsigned int&) + 352 2 JavaScriptCore 0x0000000188111678 JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally+ 2774648 () + 36 3 JavaScriptCore 0x00000001883e5d4c JSC::Heap::runEndPhase+ 5741900 (JSC::GCConductor) + 1584 4 JavaScriptCore 0x00000001883e4368 JSC::Heap::runCurrentPhase+ 5735272 (JSC::GCConductor, JSC::CurrentThreadState*) + 220 5 JavaScriptCore 0x00000001883e944c JSC::Heap::Thread::work+ 5755980 () + 32 6 JavaScriptCore 0x0000000188784c38 WTF::Function::CallableWrapper::call+ 9538616 () + 360 7 JavaScriptCore 0x0000000187e75660 WTF::threadEntryPoint+ 38496 (void*) + 120 8 JavaScriptCore 0x0000000187e755a0 WTF::wtfThreadEntryPoint+ 38304 (void*) + 84 9 libsystem_pthread.dylib 0x000000018116831c _pthread_body + 308 10 libsystem_pthread.dylib 0x00000001811681e8 _pthread_body + 0 11 libsystem_pthread.dylib 0x0000000181166c28 thread_start + 4 We have a workaround or maybe it's just a best practice implementation that resolves these crashes on iOS. Basically you can't create a new keychain item for each use, instead you have to create a singleton and handle "one-time" event listeners accordingly. On android it works fine either way.

Comments

Hans Knöchel 2018-01-29

[~btknorr] Let's tackle this! A few questions: * When authorizing the keychain item, does this only happen with Face ID or does it with Touch ID as well? * Do you have an example code for this (no worries, we can create one if not existing)? * Is this limited to specific iOS *or* Ti.Identity / Ti.TouchID versions? Thanks!

Luc-Edmond Gaspard 2018-01-30

This code can cause the crash.

   var TiIdentity = require('ti.identity');
   
   var win = Ti.UI.createWindow({layout:"vertical", backgroundColor:"white", top: 30});
   
    var btnSet  = Ti.UI.createButton({title: "set loop", bottom:"10", borderColor: "blue"});
    btnSet.addEventListener("click", function(){
   	 	setInterval(function(){
   			setObject("testkey");
   		}, 200);
    });
   win.add(btnSet);
   
    var btnGet  = Ti.UI.createButton({title: "get loop", bottom:"10", borderColor: "blue"});
    btnGet.addEventListener("click", function(){
   		setInterval(function(){
   			getObject("testkey");
   		}, 200);
    });
   win.add(btnGet);
   
   win.open();
   
   function createKeyChainItem(key) {
   		var appIdentifierPrefix = "NCCABCDEFG";
   		var keychainItem = TiIdentity.createKeychainItem({
   			identifier: key,
   			accessGroup: appIdentifierPrefix + '.' + Ti.App.getId()
   		});
   		return keychainItem;
   	}
   
   function getObject(key){
   	var keychainItem = createKeyChainItem(key);
   	keychainItem.addEventListener('read', function(e){
   		console.log("get success:", e.success, "value:", e.value);
   	});
   	keychainItem.read();
   }
   
   function setObject(key){
   	var keychainItem = createKeyChainItem(key);
   	valExists(keychainItem, function(exists){
   		if (exists) {
   				keychainItem.addEventListener('update', function(e){
   				console.log("update:" , e.success);
   			});
   				keychainItem.update("test123");
   		}else{
   			keychainItem.addEventListener('save', function(e){
   				console.log("save:" , e.success);
   			});
   			keychainItem.save("test123");
   		}
   	});
   }
   
   function valExists(keychainItem, callback){
   	keychainItem.fetchExistence(function(e) {
   		Ti.API.debug("exists: " + e.exists);
   		callback(e.exists);
   	});
   }

Hans Knöchel 2018-01-30

[~gaspard.le] In your example, you are creating scoped event listeners without removing them again, which will end of in this behavior. You still need to keep track on which events listeners you add and remove in order to properly work with keychain access on iOS. If only this kind of code is crashing, I do not see an immediate issue with this.
Luc-Edmond Gaspard 2018-01-30

Ok I thought they would be removed when the variable become out of scope. But then it still crash if I remove the event listener. But if reuse the same KeyChainItem instance, it does not crash even if I dont remove the listener.
David Jones 2018-02-08

Regarding questions in the initial comment: 1) we experienced the issue with touch id as well 2) we were creating our instance locally too, guessing the GC cleaned up either the keychain item or the handler func before the async callback was made. we should have coded to use a singleton or otherwise keep a reference to the handler and the keychain item until the callback was made 3) we experienced same issue when trying a few different versions of Ti.TouchID and Ti.Identity
Fabian Martinez 2018-06-11

I'm having a similar issue with touchId, the same crash log. If I press the home button before the touch Id alert is displayed, 50% of the time the app crashes without any console log but showing a crash log on the device like this one: Thread 17 name: WTF::AutomaticThread Thread 17 Crashed: 0 JavaScriptCore 0x0000000187d474b8 0x187ce5000 + 402616 1 JavaScriptCore 0x0000000187fdfaa4 0x187ce5000 + 3123876 2 JavaScriptCore 0x0000000187fdb114 0x187ce5000 + 3105044 3 JavaScriptCore 0x000000018830f034 0x187ce5000 + 6463540 4 JavaScriptCore 0x0000000188306440 0x187ce5000 + 6427712 5 JavaScriptCore 0x000000018830a838 0x187ce5000 + 6445112 6 JavaScriptCore 0x0000000188308b4c 0x187ce5000 + 6437708 7 JavaScriptCore 0x000000018830e274 0x187ce5000 + 6460020 8 JavaScriptCore 0x000000018878605c 0x187ce5000 + 11145308 9 JavaScriptCore 0x00000001887b22e0 0x187ce5000 + 11326176 10 JavaScriptCore 0x0000000187cf0294 0x187ce5000 + 45716 11 libsystem_pthread.dylib 0x0000000180d95220 0x180d93000 + 8736 12 libsystem_pthread.dylib 0x0000000180d95110 0x180d93000 + 8464 13 libsystem_pthread.dylib 0x0000000180d93b10 0x180d93000 + 2832 If I wait a couple of seconds and then press the app never crashes. I'm not sure what the reason could be and I haven't been able to find a workaround.
Fabian Martinez 2018-06-11

Just to be clear, I am not using a keyChainItem, just touchId.authenticate
Vijay Singh 2018-06-12

[~inzori] Can you please share your example code? Thanks!
Hans Knöchel 2018-06-12

[~inzori] Thanks for the input! As [~vijaysingh] said, your log and a tiny app.js-suitable example would be helpful as well, but I may know what's going on there. And 50 % crash rate should be easy to reproduce.
Fabian Martinez 2018-06-12

I'll try to make an example app and reproduce it, this is happening on a bigger app. All latest versions, including 7.1.1.GA.
Fabian Martinez 2018-06-12

I haven't been able to reproduce it on a sample app yet. Maybe this part of the crash log can be of any help. Incident Identifier: FD712700-05EF-4899-8392-7F68F8090810 CrashReporter Key: 1e246c1ed050bdf3f0a45a69f48a3071084f1912 Hardware Model: iPhone8,1 Process: Akimbo [2562] Path: /private/var/containers/Bundle/Application/023C561E-E128-4FC4-8AC3-6CED6AFEDAA4/XXX.app/XXX Identifier: com.inzori.xxx Version: 9.2.36 (9.2.36) Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.inzori.xxx [1124] Date/Time: 2018-06-12 10:55:28.7790 -0300 Launch Time: 2018-06-12 10:55:19.8275 -0300 OS Version: iPhone OS 11.4 (15F79) Baseband Version: 4.60.00 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x000000000000000d VM Region Info: 0xd is not in any region. Bytes before following region: 4304338931 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 00000001008f0000-0000000100f14000 [ 6288K] r-x/r-x SM=COW ...xx.app/XXX Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0] Triggered by Thread: 16
Fabian Martinez 2018-06-12

I was able to fix the issue. The app had the touchId authentication on the windows open event and on a click event of a hidden label (never used, old code). After removing the click event of the label the app stopped crashing. Don't know the reason of the crashes though.
Hans Knöchel 2018-07-23

Thanks [~inzori], happy to hear that! Resolving the issue as we haven't been able to reproduce it and you solved it as well. Thx!

JSON Source