[TIMOB-26342] iOS 12: App crashes in certain Ti.Database / Promises operations
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | High |
| Status | Resolved |
| Resolution | Not Our Bug |
| Resolution Date | 2018-09-14T17:36:04.000+0000 |
| Affected Version/s | Release 7.4.0, Release 7.5.0 |
| Fix Version/s | n/a |
| Components | iOS |
| Labels | bluebird, investigation, ios12, promise |
| Reporter | Hans Knöchel |
| Assignee | Unknown |
| Created | 2018-08-29T08:18:43.000+0000 |
| Updated | 2018-09-14T17:36:04.000+0000 |
Description
(Via Slack community)
The developer is trying to run app on iOS 12.0 Beta and it crashes with the following error logs:
App_Test 0x00000001007c5468 -[KrollEval jsInvokeInContext:exception:] (KrollContext.m:643)
App_Test 0x00000001007c23fc -[KrollBridge loadCommonJSModule:withSourceURL:] (KrollBridge.m:734)
App_Test 0x00000001007c2ec4 -[KrollBridge loadJavascriptText:fromFile:withContext:] (KrollBridge.m:922)
App_Test 0x00000001007c3124 -[KrollBridge loadAsFile:withContext:] (KrollBridge.m:986)
App_Test 0x00000001007c3338 -[KrollBridge loadAsFileOrDirectory:withContext:] (KrollBridge.m:1055)
App_Test 0x00000001007c38d4 -[KrollBridge require:path:] (KrollBridge.m:1167)
App_Test 0x00000001007c68b4 CommonJSRequireCallback (KrollContext.m:249)
App_Test 0x00000001e6e3a1d8 0x00000001e6daf000 + 569816
loadCommonJSModule after requiring a common-js file. I am not sure so far if this happens with Alloy (and the model-binding with Backbone) only or classic Titanium apps as well. The app works fine on iOS < 12, e.g. iOS 11.4.1
*Wait*. This may be unrelated to the Ti.Database code. I bet it is related to the "Bluebird" library used to handle promises that relate to the database operations. I'm pretty sure other async operations would trigger the same issue. Also, that guess is hardened by the fact that the error occurs while require'ing a CommonJS module, which..well.."app/lib/bluebird.js" is. I also remember that we had issue with the Bluebird library before. Is this still needed these days with us supporting ES6+? Please see ALOY-1604 which is about a related issue with Bluebird incl. a way around the error. I assume iOS 12 adds some ES6 API's built-ins (like some
Promisespecs), which overlap with the ones provided by Bluebird. Not wanting to drag you into this [~eharris], but you have stated good points on the other discussion and will likely have more insight here. In the meantime, I will find out what part of the library causes it. *EDIT*: Besides that, testing with 7.4.0.v20180828081144, it does not crash. Let's wait for the reporter and some more details. Removing 7.4.0 milestone again for now.Following above observation, our team tried to get rid of bluebird.js and refactored the test-app to use native promises. However, the test-app still crashes trying to Model.save() to SQLite. The refactored test-app can be found at https://github.com/sachincredible9/ModelTemplateTest/tree/feature/Appc_ES6_Promise
[~Nirmalkumar_Patel] Thanks for the feedback. One of our core-engineers and myself tried your sample app with the above 7.4.0 build and it worked fine. We will retry with your new sample-app and report back.
[~Nirmalkumar_Patel] Can I ask what version of the iOS 12 beta your device is on? I just ran the latest code provided using Titanium SDK 7.5.0.v20180829030547, and iOS 12 beta version 16A5365b on an iPhone 6 Plus and the app runs through fine with me ending with.
Hi @Ewan We retested on the following setup and latest code (using native promise) is running fine. iOS version: 16A5365b Device: iPhone6+ Appc SDK: 7.5.0.v20180829030547 We use bluebird.js extensively in our production app (.reflect, .map, custom Errors) so it wont be easy to migrate to using native promises. Right now we are refactoring our app code to move all SQLite .save()s into a .then() handler instead the mapper function of Promise.map. I will share any further observations on this thread for your information.
Thanks! Keeping this ticket open for now.
[~Nirmalkumar_Patel] Any update here?
Hi @Hans, We have worked around this issue by moving all .save()s into a .then handler. Thanks.
Thanks! I will resolve this issue for now, but keep track if there is an indicator for an SDK-side issue. Thanks again for the flexible communication!