[TIMOB-26391] iOS: App randomly freezes on iOS 12 beta when using built-in JSCore
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Critical |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2018-12-18T17:53:50.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 7.4.2 |
| Components | iOS |
| Labels | beta, freeze, ios, ios12, ui |
| Reporter | Carlos Henrique Zinato |
| Assignee | Jan Vennemann |
| Created | 2018-09-10T16:02:11.000+0000 |
| Updated | 2019-03-03T08:39:39.000+0000 |
Description
Hi there,
before Apple's event on September 12th we've decided to test our apps on iOS 12 beta and everything seems to work fine
except that the app freezes randomly on different parts of it. It could be writing some data on the database or downloading images from web.
We then have tried to isolate and make a test case where it always freezes but we could not find it.
But what we've found so far is that it always freezes when:
"run-on-main-thread" is set to true. Never freezes when this is disabled
Running on iOS 12. Everything is fine on iOS 11
Running with Ti SDK - 7.1.0.GA and latest release 7.4.0.RC
Building from both Xcode 9 and 10. This also happens on iOS 12 simulators
We also tried checking Instruments and Console to see if we can find some errors before it freezes but nothing weird
is displayed on them nor a memory warning/leak.
The biggest challenge here is to find a very isolated and reproducible case where it will always freeze.
We found another community member with the same problem but maybe not so many members have iOS beta versions installed on their devices.
I think Carlos is mentioning me in the description and face the same problem. I'd like to drill down on this problem, but have no pointers where to start as it's occurring completely random. As mentioned it's occurring on both the simulators and real devices.
Do you use specific setTimeout or setInterval API's? Maybe there is a deadlock when using those. I am trying my best to troubleshoot this together with you guys. Thanks!
I don't exactly understand what you mean with API's in the context of setTimeout & setInterval, but I'm not using that kind of logic when bridging from Javascript to Native. What I'm doing though is using _.defer() a lot based on the knowledge shared by Ronald Treur: https://www.slideshare.net/ronaldtreur/titanium-making-the-most-of-your-single-thread
Just to chime in, we are also seeing this issue on iOS 12. Its very random in frequency but in our case it appears to happen only when the app resumes from the background. In the Resumed event we are using a _.defer(). The deferred function is checking for Geofence permission and starting/stopping and based on that loading geofences or not. Update: removed _.defer, no change.
I have the same issue with an application in production. it freezes each second time when window with ti.map is opened. I'm gong to re-test app with "run-on-main-thread" is set to false and don't have any ideas what to do next. Please help.
Also having the same issue. Its very difficult to isolate on a production app, due to the multiple dependencies, also there is nothing in the logs, or anything. It seems that its a black box error, so no visibility on why.
For me, setting run-on-main-thread to false fixes the problem 100%. Tested with GM version of iOS 12 beta and Xcode.
I have a few things that works only with run-on-main-thread so I'm in dead lock with this issue. :( Please help...
Thanks for the responses everyone! We are actively looking into this ATM. If anyone can share his/her app with me, I'd highly appreciate it. It can be sent to hknoechel@axway.com, thx! [~vijaysingh] Let me know your investigations on this one.
Hans have sent you an invite to our repo on github. If you have questions please reach out to ianko or bduyng on ti.slack.
After a few days testing we think it is in fact related to use of setInterval. We are able to reach a no hang state by not using setInterval. Hans, I have sent you an email and access to our repo.
Thanks Nick! I am testing your project right now. We are continuing to investigate in the setInterval / setTimeout direction, since these are also JSCore based and may have changed internally in iOS 12. *EDIT*: Looking into the code, there is indeed a [difference](https://github.com/appcelerator/titanium_mobile/blob/master/iphone/Classes/KrollTimer.m#L106-L117) between kroll- and main-thread in the timer-management, resulting in a threading issue after some time. If someone can comment out line 106-113 and let me know the results, I'd appreciate it, since I'm still not able to reproduce the bug.
Cheers Hans, I ran up a build with those lines commented out and have had UI hang on boot. I once got into the UI after resetting the simulator (so forcing the user to log out of the app). But once in I had a hard crash. After that it was back to the hang on splash.
Thanks Nick! We will dig into this next week.
I'll also look in this issue. If someone can please share your app with me at vsingh@axway.com, would be great. Thanks!
I've sent you an invite Vijay!
Thanks Nick for sharing your app! I have tried to reproduce the issue with app but unable to reproduce the issue. Is there any particular steps to reproduce it? Can you please try to test it by replacing 'NO' with 'YES' at line no 111 [here](https://github.com/appcelerator/titanium_mobile/blob/master/iphone/Classes/KrollTimer.m#L111). Thanks!
No problem, I have just sent a build out to our team tonight for testing with that change. One of the challenges has been consistency. On some devices it manifests quickly (on a test iPhone X we have running iOS 12, it occurs several times an hour) but on others (iphone7+) it can be 24hours+ of running before we see the issue. With our particular app, it only happens when you have the pill moved over to locations (on the greetings screen). This does a setInterval. With this on, it will randomly UI hang. With this slider set to manually it never hangs.
An update: We have been running for 2 days now, no hangs with this change! That flag seems to have solved it. Will keep updating if there are any changes
Thanks for update Nick! Can other people also please verify with following changes - Test it by replacing 'NO' with 'YES' at line no 111 [here](https://github.com/appcelerator/titanium_mobile/blob/master/iphone/Classes/KrollTimer.m#L111). Thanks!
PR (7_4_X) - https://github.com/appcelerator/titanium_mobile/pull/10327 PR (master) - https://github.com/appcelerator/titanium_mobile/pull/10326
I replaced this with YES but still app is crashing on one particular main screen... Operating System Name = Mac OS X Version = 10.13.6 Architecture = 64bit # CPUs = 4 Memory = 8.0GB Node.js Node.js Version = 8.9.1 npm Version = 5.10.0 Appcelerator CLI Installer = 4.2.13 Core Package = 7.0.6 Titanium CLI CLI Version = 5.1.1 node-appc Version = 0.2.44 Titanium SDKs 7.4.0.GA Version = 7.4.0
I've just tested on both 7.1.0.GA and 7.4.0.RC and still the same. Just to make sure, I'm changing from NO to YES on KrollTimer.m line 111, cleaning my project and building it again (deleting the app). Tested it 3 times on different devices, always cleaning the project. Still the same =/ I can share an .IPA file if you want it so you can see the logs if it helps
Please note that your app still could crash because of other iOS 12 related deprecations or removals. For example, memory leaks in your controllers could have been ignored on iOS 11.x but may be causing a crash on iOS 12 now. We need an isolated test project to reproduce this in order to properly fix all occurences of this crash. Also, it seems like no one is able to provide a symbolicated crash report or log so far, which makes it impossible to fix.
I can send you my app on email id provided would you be able to test it on your end, For me it is crashing on only one image screen, if I don't go to that part everything is working fine
I've tested this too and am getting startup crashes and other freezes very frequently with ios12/7.4.X and XCode 10. All was fine with iOS11/7.3.0/XC 9 - I will look harder to find the cause, it's a real challenge to get crash logs though as the app cannot be directly built with XCode (missing resources etc...) - This should really be possible!!. As a workaround I create a tishadow app and because of the way it is packaged, I can rebuild that app in XCode directly and the resources are present, which gives far superior debug-ability - it does however add another variable to the mix :/
UPDATE: I experienced our first UI hang last night on my own device, since making the change. Massive decrease in occurrences, however the issue is still there for us. Hans: We're not seeing crashes in our app, just UI hangs, so nothing to provide as output.
We are getting the freezes and crashes for our apps as well using all the latest, iOS12, XCode 10, Ti 7.4.0.GA. Our clients are getting upset. Any progress on this?
Not sure if it helps, but I've obbserved that some of the crashes are related to the freeze. e.g when the app is frozen it will generally stay alive (and not crash). It will however crash ~180 seconds after backgrounding as the system will be unable to take a screen snapshot - presumably because the main thread is unresponsive.
Sep 19 21:38:38 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Sending background permission expiration warning! Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Forcing crash report with description: MyApp:1529 has active assertions beyond permitted time: Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Finished crash reporting. Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] dump assertions count:2 HWM:4 (CPUMON check): { Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] setpriority(PRIO_DARWIN_ROLE, 1529, 3): ok Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Ignoring assertion remove, because we are terminated or pending termination Sep 19 21:38:43 GB-iPhoneX mediaserverd(AudioToolbox)[491] <Notice>: 4213: { "action":"destroy_session", "session":{"ID":"0x1ed57a","PID":1529,"name":"MyApp","type":"Fig"}, "details":null } Sep 19 21:38:43 GB-iPhoneX mediaserverd(AudioToolbox)[491] <Notice>: 105: { "action":"client_died", "session":{"ID":"0x1ed57b","PID":1529,"name":"MyApp"}, "details":null } Sep 19 21:38:43 GB-iPhoneX ReportCrash[1545] <Notice>: Formulating report for corpse[1529] MyApp Sep 19 21:38:43 GB-iPhoneX ReportCrash(CrashReporterSupport)[1545] <Notice>: Process: MyApp [1529] Path: /private/var/containers/Bundle/Application/8817982C-F11D-4F2C-A44C-2A042427A473/MyApp.app/MyApp 6 MyApp 0x0000000104d51994 0x104a5c000 + 3103124 5 MyApp 0x0000000104b940cc 0x104a5c000 + 1278156 6 MyApp 0x0000000104b4e580 0x104a5c000 + 992640 7 MyApp 0x0000000104b4e7a4 0x104a5c000 + 993188 8 MyApp 0x0000000104a61b30 0x104a5c000 + 23344 9 MyApp 0x0000000104b63fcc 0x104a5c000 + 1081292 10 MyApp 0x0000000104a88810 0x104a5c000 + 182288 11 MyApp 0x0000000104a86e68 0x104a5c000 + 175720 5 MyApp 0x0000000104b940cc 0x104a5c000 + 1278156 6 MyApp 0x0000000104a8d8a0 0x104a5c000 + 202912 Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Port death watcher fired. Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: Process exited: <BKProcess: 0x102f1dac0; MyApp; com.MyApp.MyApp; pid: 1529; agency: Application; visibility: none; task: none; hostpid: 55> Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Invalidating... Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Ignoring assertion remove, because we are terminated or pending termination Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Got exit context: <BKSProcessExitContext: 0x102d02bc0; reason: (none)> Sep 19 21:38:43 GB-iPhoneX SpringBoard(FrontBoard)[55] <Notice>: <FBApplicationProcess: 0x113a037f0; MyApp (com.MyApp.MyApp); pid: 1529> assertiond says the process actually exited with context: <BKSProcessExitContext: 0x282f83fa0; reason: (none)> Sep 19 21:38:43 GB-iPhoneX SpringBoard(FrontBoard)[55] <Notice>: <FBApplicationProcess: 0x113a037f0; MyApp (com.MyApp.MyApp); pid: 1529> exited. Sep 19 21:38:43 GB-iPhoneX SpringBoard(FrontBoard)[55] <Notice>: Removing: <FBApplicationProcess: 0x113a037f0; MyApp (com.MyApp.MyApp); pid: -1> Sep 19 21:38:43 GB-iPhoneX SpringBoard[55] <Notice>: Process exited: <FBApplicationProcess: 0x113a037f0; MyApp (com.MyApp.MyApp); pid: -1> -> <FBApplicationProcessExitContext: 0x2823dd740; exitReason: (none); terminationReason: (none)> { Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Terminating because the job-submitter has disconnected. Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Deleted launchd job with label: UIKitApplication:com.MyApp.MyApp[0xf015][65] Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Invalidation complete. Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] Removing client: <BKProcessInfoServerClient: 0x102828ed0; pid: 55> Sep 19 21:38:43 GB-iPhoneX assertiond[65] <Notice>: [MyApp:1529] No clients remain.Using instruments with a patched SDK with the fix: I can see a leak from our use of setInterval. Leak stops after clearInterval.
Hi guys! Our team faced the same issues right before application launch in production. It freezes or crashes frequently without specific steps to reproduce. Setting preference to YES in KrollTimer.m unfortunately was not helpful - seems application did not freeze but crashes much frequently (in some cases it is related to TI.Database). Could you please tell do you have any updates regarding these issues and when we can expect SDK update? Thanks in advance!
Regarding the possibility of setInterval and setTimeout being the culprit, I've been running this simple test app.js : [Gist Test app.js for TIMOB-26391](https://gist.github.com/kosso/540fdb1f24dc44152d9e6588ee57088f) Note: when the app is put to the background, the setInterval pauses until the app is resumed. (Is that expected behaviour?) However: interestingly, if I register a background service script (even an empty js file!) when the app pauses, the intervals and timeouts all work as normal while the app is in the background. Update: In the background script, if I also add another setInterval and setTimeout similar to the ones in app.js, even though I'm stopping and unregistering the background script when the app resumes, the background setInterval and setTimeouts are still firing and logging to the console. So they're not being cleared. And if I then go to the background again, the intervals and timeout are being duplicated. Something is certainly wrong there. Update2: The the invervals running in the background service do actually stop after 180 seconds, after the
assertiondprocess sends "Sending background permission expiration warning!" to the log.Similar observation from our production apps. Random crashes in the initial sync during launching the app which is all API calls and persisting the received responses into SQLite DB. No use of setInterval in our codebase.
Hey @Greg thanks for your input. I think this makes a lot of sense since some of my clients are complaining that the app is crashing much more often then before and I knew it was a side effect of keeping the run-on-main-thread FALSE. So the app is actually "freezing" but because the UI is running on a different thread, we can not notice the "freeze". Than like you've said, it will crash after ~180 seconds. @kosso, I'm trying your test cases but they are not freezing on iOS 12 =/ Any other idea anyone?
I don't know why they have put this issue as resolved, I am having the same issue and my App is getting crashed on one screen.. And its not resolved yet, I have tried all different options but I am not able to solve it out.
It's not as resolved, it says "Unresolved" and "In Review"....let's hope they find something. Fingers crossed
@Carlos The test app was to try and see if the intervals were the cause. I was trying to speed up crash testing. But on the way, found some interesting phenomena regarding timers on background services. (But since the timers alone don't actually create any 'audio', 'fetch', 'location', etc. actions, the system will kill the background tasks after 180 seconds. I still get random freezes in my apps, as described. But sometimes it can be after an hour. Sometimes after running for 12 hours. One thing I did notice today, after testing an app overnight, is that I added the fix for Ti.App events from TIMOB-26369 and today I saw my app actually react to a 'memorywarning' event. The app did not crash, but an alert (which I had programmed in the listener) did show up. I also spent all night re-writing some of the functionality my app needs to do on the network in to a custom native module using GCD for the tasks. This has dramatically improved performance of certain tasks (eg: lazy-loading 200+ row tableViews with remote/cached images.) But I don't think it's 100% related to this issue. Also, a couple of people have mentioned SQLite being a potential culprit. My app does a lot of regular SQLite work for logging etc. on a very regular basis, every 5 minutes or so, and also each few hours to generate JSON from it and POST to our servers. This all seems to have been working fine. The 'KrollTimer.m' YES/NO fix and run thread setting doesn't seem to have made much difference.
Quick update: We are still investigating this ticket and are finally able to reproduce the issue. While doing that, we also pinpointed it down to calls with Ti.Network.HTTPClient that fire a callback which causes the crash (only when using main-thread as known already). For an insight: [This](https://github.com/appcelerator/titanium_mobile/blob/master/iphone/Classes/KrollObject.m#L1077) is where it crashes exactly - the kroll- and main-thread related changes can also be seen in there. We are actively working on a fix right now and will keep this ticket updated. To keep the ticket chronic clean, please prevent posts like "same here" and follow this ticket instead. Thank you!
This is not "the same" post. We have an application with offline mode (but with ti.googlemap module with prechased maps). it works without any HTTPClient calls but it freeze each 2-3 time when window with googlemap is opened. UPDATE: I added couple of "ENSURE_UI_THREAD" to ti.googlemap and we published new version with run-on-main-thread: false. Now it works so we can wait for fix. Unfortunately, I can't share the app. :( Good luck with investigation and I'm ready to help with testing - contact me as @darknos at ti-slack if need.
Greetings, I have been able to successfully work-around this bug by doing the following things: - Change my background task spawned inside of index.js from using setInterval to using setTimeout+Recursion to keep running. - Change my SDK from the GA release to "*7.4.1.v20180920040600*". setInterval appears to be the problem for me. By implementing the two things above, I'm running almost 100% stable now on iOS12 from my testing so far. I am able to leave
run-on-main-threadenabled in this configuration, meaning Hyperloop still works for me.@Josh. I'm currently looking at forking and updating a native timer module to replace (or provide some parity to) setInterval and setTimeout here> https://github.com/kosso/ti.mely Having tried the run-on-main-thread options and other possible fixes above, I've still had an app lock up. Sometimes, it has locked up around a time in my app 'near' where I make 'heavy' use of setInterval (to crossfade two audio players). Sometimes the lockup happens after a couple of hours. Sometimes, many more. But often around the same point in my app's processes where setInterval is employed.
@Josh this didn't fix my app. Doesn't seem to be something in one place like HTTP or interval, maybe a bunch of things combined. My app also freezes when the phone is on Airplane mode =/ @kosso nice work with these native intervals/timeout! Hope you can progress on that! (why JIRA's user mention tool is so useless like this?)
Quick update: We investigated this further over the weekend could get a successful result if the following flag is set in the
<use-jscore-framework>false</use-jscore-framework>Awesome! Gonna test this and let you know @Hans! Do you know when use-jscore-framework started to be supported by Titanium?
Supported since SDK 5, made default in 7.0.0+ (which also explains why 6.3.0 worked and 7.0.0 not). The underlaying issue is about GC'ing objects on the low-level side of the SDK. Keeping this thread updated.
Exactly! That's why I've just asked...and because I just found this: "With Titanium SDK 6.x, developers must add a tag to enable the iOS debugger in order to use Safari (or iOS-webkit-debug-proxy). With SDK 7.x and later, this value is assumed to be true unless you explicitly add the tag with false as the value." Testing it here and let you know right away
@Carlos (and anyone else interested to try it) I have updated my fork of the 'ti.mely' module to include setInterval and setTimeout methods with the same structure and callbacks as the 'native' JavaScript functions. https://github.com/kosso/ti.mely (Now with iOS and Android included) I'm thinking that maybe a native solution for timers might be a safer approach?
Some more info... we have one app that uses setInterval to retrieve remote data periodically and it freezes a lot, but after setting run-on-main-thread to false, it seems to work fine. We can do this because we do not use Hyperloop in this app. However in one of our client's apps, we use Hyperloop so we cannot do this. Our client's app doesn't use setInterval, and it freezes up by just making a simple network call (like logging in) and then updating the ui. So while setTimeout and setInterval may cause this issue to happen more often, it doesn't seem to be the root cause - at least in our case. Thanks!
[~btknorr] Did you also test with the recommended property by [~hknoechel] above?
<use-jscore-framework>false</use-jscore-framework>Great add @Brian! Thanks for sharing. Just so you know, I can confirm that setting "use-jscore-framework" to false on tiapp.xml fixed the issue on iOS 12 with no other side effects. Tested on both iOS 12 and 11 and with Titanium SDK 7.1.0 and 7.4.0, the app never freezes again. Thanks everyone!
We are starting to test with this set to false right now...I will let you know. Thanks!
When setting this to false the app immediately crashes on startup and we get a hyperloop warning that we should set use-jscore-framework to true. So this unfortunately is not a fix for hyperloop apps.
*EDIT Sep 25*: setting the property
seems to work fine! The app is not crashing now. My problem after setting this property was that ES6 was not supported anymore. --------------------------------------------------------------------- *ORIGINAL POST:* I'm not experiencing freezings but crashes with iOS 12 (iPhoneX device) and Ti SDK 7.4.0.GA. Everything was smooth on iOS 11 and Ti SDK 7.3.1.GA. Changing this property flagto false didn't make a difference. This app uses joli.js library as adapter for the models. I could isolate the crash to always the same line, but it's totally random, sometimes I can add like 20 items to a listview and to the model and it works fine, sometimes it crashes after 3 or 9... no special conditions are met for the crash. This linevar db = Titanium.Database.open('dbname');db.execute('PRAGMA read_uncommitted=true');Greetings, Per the above suggestion from *@Hans* and *@Rene*, I added the following to the *
<use-jscore-framework>false</use-jscore-framework>Doing this causes my app to crash immediately on boot. * We use Hyperloop * We have *run-on-main-thread* enabled. * We use Localytics via Hyperloop and this module: https://github.com/centrevilletech/localytics-hyperloop When the crash happens, nothing gets sent to the logs, so I'm unsure what's happening here.To those who are updating their tiapp.xml with the jscore tag, but encounter a crash on launch: If you use the com.appcelerator.apm module and it is version 3.0.0 or earlier, it is unsupported on iOS 12 and can cause the crashes you are seeing. Please update to 3.1.0 or higher.
Just FWIW: My app has been running OK (so far) for about 5 hours or so on two devices: - iPad 5thGen - iOS 12 - iPad2 - iOS 9.3.5 (!) Built with Ti SDK 7.3.1.GA and XCode9 installed. (I have yet to make the Xcode 10 leap) The app includes many custom modules: a custom audio player x 2, audio file decryption, media file inspection, mass download batch management, a new native timer for audio crossfades and other duties, frequent SQLite usage and various secure API calls via Ti.Network.HTTPClient. Note: it does not use Hyperloop. And it is a 'classic' app. Not alloy. I'll be keeping an eye on them all night, but they're running fine so far with 'run-on-main-thread' set to true and 'use-jscore-framework' set to false.
@Eric Wieber I'm on 3.1.2 of com.appcelerator.apm and still get the crash. Doesn't appear to fix it for me.
We are also on 3.1.2 of apm and get the crash on startup with run-on-main-thread true and use-jscore-framework false. Again we use Hyperloop in this app...specifically for card.io
Just to update on my extended tests: iPad2 stopped overnight but was still responsive, though no memorywarning alert or anything). iPad5th just crashed and closed after running for over 12 hours. (No ability to get logs until I update to XCode 10 - and I didn't have the console open at the time). Also an 11.4 iPhone Simulator also just crashed. The crashed thread log has multiple mentions of com.apple.JavascriptCore despite it being disabled in tiapp.xml. Here's the crashed thread:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Trace/BPT trap: 5 Termination Reason: Namespace SIGNAL, Code 0x5 Terminating Process: exc handler [0] Application Specific Information: CoreSimulator 518.22 - Device: iPhone 6 - Runtime: iOS 11.4 (15F79) - DeviceType: iPhone 6 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.JavaScriptCore 0x00000001169bf1a3 bool JSC::Structure::checkOffsetConsistency<JSC::Structure::checkOffsetConsistency() const::'lambda'()>(JSC::PropertyTable*, JSC::Structure::checkOffsetConsistency() const::'lambda'() const&) const::'lambda'(char const*)::operator()(char const*) const + 259 1 com.apple.JavaScriptCore 0x00000001169bed98 JSC::Structure::checkConsistency() + 200 2 com.apple.JavaScriptCore 0x000000011720b1fd JSC::Structure::add(JSC::VM&, JSC::PropertyName, unsigned int) + 125 3 com.apple.JavaScriptCore 0x000000011720aeaa JSC::Structure::addNewPropertyTransition(JSC::VM&, JSC::Structure*, JSC::PropertyName, unsigned int, int&, JSC::PutPropertySlot::Context, JSC::DeferredStructureTransitionWatchpointFire*) + 442 4 com.apple.JavaScriptCore 0x00000001169be537 bool JSC::JSObject::putDirectInternal<(JSC::JSObject::PutMode)1>(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int, JSC::PutPropertySlot&) + 1719 5 com.apple.JavaScriptCore 0x000000011712b1ec JSC::putDescriptor(JSC::ExecState*, JSC::JSObject*, JSC::PropertyName, JSC::PropertyDescriptor const&, unsigned int, JSC::PropertyDescriptor const&) + 524 6 com.apple.JavaScriptCore 0x000000011712a4a1 JSC::validateAndApplyPropertyDescriptor(JSC::ExecState*, JSC::JSObject*, JSC::PropertyName, bool, JSC::PropertyDescriptor const&, bool, JSC::PropertyDescriptor const&, bool) + 577 7 com.apple.JavaScriptCore 0x000000011710f635 JSC::JSObject::defineOwnProperty(JSC::JSObject*, JSC::ExecState*, JSC::PropertyName, JSC::PropertyDescriptor const&, bool) + 421 8 com.apple.JavaScriptCore 0x00000001169e6c25 JSObjectSetProperty + 261 9 com.amazingmedia.instore1 0x000000010df3aa0b -[KrollObject noteObject:forTiString:context:] + 267 (KrollObject.m:1177) 10 com.amazingmedia.instore1 0x000000010df3643e KrollGetProperty + 1550 (KrollObject.m:218) 11 com.apple.JavaScriptCore 0x00000001169db26d JSC::JSCallbackObject<JSC::JSDestructibleObject>::getOwnPropertySlot(JSC::JSObject*, JSC::ExecState*, JSC::PropertyName, JSC::PropertySlot&) + 461 12 com.apple.JavaScriptCore 0x0000000116f03a58 llint_slow_path_get_by_id + 5384 13 com.apple.JavaScriptCore 0x000000011699cb5f llint_entry + 12637 14 com.apple.JavaScriptCore 0x000000011699981a vmEntryToJavaScript + 304 15 com.apple.JavaScriptCore 0x0000000116e7ad43 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 147 16 com.apple.JavaScriptCore 0x0000000116e3777b JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 523 17 com.apple.JavaScriptCore 0x000000011703f6d1 JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 177 18 com.apple.JavaScriptCore 0x00000001169e8040 JSObjectCallAsFunction + 496 19 com.amazingmedia.instore1 0x000000010e18a5e6 __TiBindingEventProcess_block_invoke + 86 (TiBindingEvent.m:269) 20 com.amazingmedia.instore1 0x000000010e03855d TiThreadPerformOnMainThread + 77 (TiBase.m:317) 21 com.amazingmedia.instore1 0x000000010e18a48e TiBindingEventProcess + 1054 (TiBindingEvent.m:265) 22 com.amazingmedia.instore1 0x000000010e18a778 -[TiBindingCallbackInvoke invoke:] + 56 (TiBindingRunLoop.m:51) 23 com.amazingmedia.instore1 0x000000010df2d41f -[KrollContext invoke:] + 159 (KrollContext.m:990) 24 com.amazingmedia.instore1 0x000000010df2d4fa __24-[KrollContext enqueue:]_block_invoke + 42 (KrollContext.m:1016) 25 libdispatch.dylib 0x000000011adc36cb _dispatch_call_block_and_release + 12 26 libdispatch.dylib 0x000000011adc4709 _dispatch_client_callout + 8 27 libdispatch.dylib 0x000000011adce708 _dispatch_main_queue_callback_4CF + 1279 28 com.apple.CoreFoundation 0x0000000116431c99 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 29 com.apple.CoreFoundation 0x00000001163f5ea6 __CFRunLoopRun + 2342 30 com.apple.CoreFoundation 0x00000001163f530b CFRunLoopRunSpecific + 635 31 com.apple.GraphicsServices 0x000000011929ca73 GSEventRunModal + 62 32 com.apple.UIKit 0x0000000110d6e057 UIApplicationMain + 159 33 com.amazingmedia.instore1 0x000000010df12f34 main + 100 (main.m:30) 34 libdyld.dylib 0x000000011ae39955 start + 1videosubscriptionsdprocess in loop, complaining about "Unable to find framework using path: /System/Library/Frameworks/VideoSubscriberAccount.framework". Which is weird, since it's on the simulator. I have a feeling this is related to the Apple News app background refreshes. Also, on the iPad5th which crashed and closed, I noticed the icons at the bottom of the screen changing a few times, more than usual, which is the 'handoff' feature trying to do things. No idea if this is related.Hi everyone, indeed, with the use-jscore-framework setting set to false, the app never freezes but started to crash more often. This is becoming very stressing =/
Hey Hey, I also wanted to chime in just to note that my latest app crashes on startup (every time), _both_ device & simulator with:
<use-jscore-framework>false</use-jscore-framework>Another downside of reverting the use of jscore framework to 'false' is the fact that you could run into some issues in regards to the ECMA script support you got when using the 'true' mode. Some of the Javascript I wrote cannot be interpreted anymore when setting to false.
After spending the last few days trying to figure out what is going on, and reviewing everyones comments and suggestions, the following things are clear to me (nothing that hasn't been said before, I just wanted to summarise my thoughts): * There is something fundamentally different about how iOS 12 works, and it is not behaving well with Ti 7.4.0/Xcode 10 * The issues are not easily reproducible * The issue is not isolated to using jscore (or not) * The issue is not isolated to using main thread (or not) * Some users are experiencing the app "hanging", others "crashing" * There are frequent references to setTimeout / setInterval - there must be something in that For my experience, I do not use Alloy - all my apps are classic. The issues for me are random, but frequent. I do not really have apps "hanging" - but I do see my apps "crashing". Sometimes on startup, sometimes at other places in the app flow. Some patterns have emerged: * There is definitely something odd going on with setTimeout. Don't ask my what as I cannot get a clear picture, but a percentage of the crashes do seem to happen when there are timeouts involved. * I use JSON file stores a lot in my apps. Mainly because they have been so performant in all versions of iOS / Ti up till now. But there are definitely random issues related to loading files, parsing JSON and then the reverse - stringify and write file. I should mention that there were some reproducible crashes occurring related to memory usage. Using Instruments I managed to track them down and improve the code, and that has made a difference. This code worked fine on iOS 6-11, but all of a sudden an issue with iOS 12 - which lines up with the changes Apple said they were going to make around iOS 12 performance/memory usage I guess. But stepping back from these memory issues I managed to address, I am left with these random crashes. Every time I think I have fixed it by changing the flow of logic in the code, or the use of timeouts etc, I come back later and test again, and "crash" again :( Anyway ... at this stage I am a bit lost on how to proceed. I know the team is working very hard on this. But I am hoping that there is more on the table than just "disable jscore"? Are there other recommendations I can try? Overall I guess I am wanting reassurance that I am not the only one having issues in the areas of code I have described.
[~ppancholi] Can you please share your app on my email id vsingh@axway.com. Please mention the steps to reproduce the same. As your app in crashing on a particular screen, so it may be we can create a smaller test case with that to debug. Thanks!
I am also seeing my app crash at random times, I will try to find a reproducible case but at this stage its only happened once or twice on the simulator a few seconds after startup - with no logs running hyperloop and have added tag to disable jscore
What is maybe slowing down our process is that we can't see any error or logs when the app crashes or freezes. Can we add some logs on the iOS SDK so we start receiving them?
This is the crash log from my device. It doesn't crash if I add
under the ios tag in tiapp.xml.Incident Identifier: 54E92F74-F794-4843-83BD-B584C4E67033 CrashReporter Key: baa84a1f39eac58e0e9713e3266d1c452fb3b628 Hardware Model: iPhone10,3 Process: DEV [4062] Path: /private/var/containers/Bundle/Application/FEE803AB-7E72-4C93-A51A-CAD3E71DB0B4/DEV.app/DEV Identifier: Version: 6.3.0 (6.3.0) Code Type: ARM-64 (Native) Role: Non UI Parent Process: launchd [1] Coalition: [1912] Date/Time: 2018-09-26 12:17:25.0612 -0300 Launch Time: 2018-09-26 12:16:25.1686 -0300 OS Version: iPhone OS 12.0 (16A366) Baseband Version: 3.00.00 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x00000003274a19e8 VM Region Info: 0x3274a19e8 is not in any region. Bytes after previous region: 2269780457 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL MALLOC_NANO 0000000280000000-00000002a0000000 [512.0M] rw-/rwx SM=PRV ---> UNUSED SPACE AT END Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [4062] Triggered by Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 JavaScriptCore 0x00000001c280827c JSC::LLInt::setUpCall+ 7848572 (JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 292 1 JavaScriptCore 0x00000001c28081a4 JSC::LLInt::setUpCall+ 7848356 (JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 76 2 JavaScriptCore 0x00000001c20f5120 llint_entry + 29952 3 JavaScriptCore 0x00000001c20f54e0 llint_entry + 30912 4 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 5 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 6 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 7 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 8 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 9 JavaScriptCore 0x00000001c20f5134 llint_entry + 29972 10 JavaScriptCore 0x00000001c20f5598 llint_entry + 31096 11 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 12 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 13 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 14 JavaScriptCore 0x00000001c20f5598 llint_entry + 31096 15 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 16 JavaScriptCore 0x00000001c20f5134 llint_entry + 29972 17 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 18 JavaScriptCore 0x00000001c20f50cc llint_entry + 29868 19 JavaScriptCore 0x00000001c20f5134 llint_entry + 29972 20 JavaScriptCore 0x00000001c20f5134 llint_entry + 29972 21 JavaScriptCore 0x00000001c20f5134 llint_entry + 29972 22 JavaScriptCore 0x00000001c20eda1c vmEntryToJavaScript + 300 23 JavaScriptCore 0x00000001c27653f0 JSC::Interpreter::executeCall+ 7181296 (JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 424 24 JavaScriptCore 0x00000001c291c068 JSC::profiledCall+ 8978536 (JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 172 25 JavaScriptCore 0x00000001c2123284 JSObjectCallAsFunction + 368 26 DEV 0x0000000103056880 __TiBindingEventProcess_block_invoke + 1861760 (TiBindingEvent.m:269) 27 DEV 0x0000000102f71944 TiThreadPerformOnMainThread + 923972 (TiBase.m:317) 28 DEV 0x0000000103056744 TiBindingEventProcess + 1861444 (TiBindingEvent.m:265) 29 DEV 0x0000000103056a5c -[TiBindingCallbackInvoke invoke:] + 1862236 (TiBindingRunLoop.m:51) 30 DEV 0x0000000102eae398 -[KrollContext invoke:] + 123800 (KrollContext.m:990) 31 DEV 0x0000000102eae494 __24-[KrollContext enqueue:]_block_invoke + 124052 (KrollContext.m:1016) 32 DEV 0x0000000102f71944 TiThreadPerformOnMainThread + 923972 (TiBase.m:317) 33 DEV 0x0000000102eae454 -[KrollContext enqueue:] + 123988 (KrollContext.m:1019) 34 DEV 0x0000000103056ae0 TiBindingRunLoopEnqueue + 1862368 (TiBindingRunLoop.m:58) 35 DEV 0x0000000103055ff4 TiBindingEventFire + 1859572 (TiBindingEvent.m:181) 36 DEV 0x0000000102f4e500 -[TiProxy fireEvent:withObject:propagate:reportSuccess:errorCode:message:] + 779520 (TiProxy.m:909) 37 DEV 0x0000000102ed07c8 -[TiViewProxy fireEvent:withObject:propagate:reportSuccess:errorCode:message:] + 264136 (TiViewProxy.m:1807) 38 DEV 0x0000000102f4e1a8 -[TiProxy fireEvent:withObject:] + 778664 (TiProxy.m:855) 39 DEV 0x0000000103075ba8 -[TiUIListView fireClickForItemAtIndexPath:tableView:accessoryButtonTapped:] + 1989544 (TiUIListView.m:2245) 40 DEV 0x00000001030727fc -[TiUIListView tableView:didSelectRowAtIndexPath:] + 1976316 (TiUIListView.m:1828) 41 UIKitCore 0x00000001e7baa6f4 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1348 42 UIKitCore 0x00000001e7baa958 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 268 43 UIKitCore 0x00000001e76af190 _runAfterCACommitDeferredBlocks + 296 44 UIKitCore 0x00000001e769d1d0 _cleanUpAfterCAFlushAndRunDeferredBlocks + 384 45 UIKitCore 0x00000001e76cc508 _afterCACommitHandler + 132 46 CoreFoundation 0x00000001bad7db94 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32 47 CoreFoundation 0x00000001bad78828 __CFRunLoopDoObservers + 412 48 CoreFoundation 0x00000001bad78dc8 __CFRunLoopRun + 1264 49 CoreFoundation 0x00000001bad785b8 CFRunLoopRunSpecific + 436 50 GraphicsServices 0x00000001bcfec584 GSEventRunModal + 100 51 UIKitCore 0x00000001e76a3558 UIApplicationMain + 212 52 DEV 0x0000000102e989e4 main + 35300 (main.m:30) 53 libdyld.dylib 0x00000001ba838b94 start + 4We finally isolated the issue and have an initial fix ready for you guys. Please check the SDK from the following PR and let us know if it works for you. PR: https://github.com/appcelerator/titanium_mobile/pull/10352
Amazing! Testing it right now and can give you some feedback ASAP
Hi.Good news! Can you confirm which tiapp.xml settings we should be testing with for
andthanks![~kosso] Any combination should work now. But default -
@Vijay Singh - should we just patch the two files in our SDK as in the pull request or how do we get the correct SDK for testing? In this PR: https://github.com/appcelerator/titanium_mobile/pull/10352
That's is a good question. How 'back-portable' is this fix? Will it help earlier version of the SDK? (eg: 7.3.1.GA) thanks!
[~dieskim] Patching your sdk with this change is the best way to test now. This change will go in 7.4.1 SDK.
Initial testing against 7.4.0.GA with the patch is looking very positive. No crashes yet!
I can only imagine the effort that went into those 6 lines of code. Thanks so much team for your efforts.
How do I go about about getting the patched SDK? We're experiencing this same issue in all of our apps and it's put us in a broken state.
How can I get 7.4.1.GA, When I try to install through appc ti sdk install with 7.4.1 it says 7.4.0 is the latest version
Amazing job guys! Our app implementation feels rock solid again after patching the 7.2.1 SDK. Thank you so much for the effort!
@Taylor Thompson https://www.appcelerator.com/blog/2018/06/patch-titanium-sdk-using-cherry-picking/ Or if you just want to test with latest:
git clone https://github.com/appcelerator/titanium_mobile.git git checkout 7_4_X cd titanium_mobile/build npm install node scons.js cleanbuild iosThe patch was merged and you can now get the fixed SDK directly via CLI if you select the 7_4_X branch:
appc ti sdk install -b 7_4_XGreat work guys! It doesn't seem to freeze anymore with both flags set to TRUE. Do you guys mind sharing how did you manage to isolate the problem? Or how did you find what was causing the issue? Thanks for the effort everyone
+1 I was going to ask the same questions...
I tested this fix to see if it fixed AC-5928 and I am still seeing the original problem described in that ticket. Should it have resolved that issue as well? I have run-on-main-thread set to true and removed the jscore line so it should be true now. 7.4.1.v20180927102822 is the SDK version I am using after running:
appc ti sdk install -b 7_4_XWith the updates on sdk 7.4.1 (Thu Sep 27) in random times i get a black screen and app stops running. On previous versions of sdk 7.4.1 this issue did not appear. :(
[ERROR] : The application has crashed with an uncaught exception 'NSInvalidArgumentException'. [ERROR] : Reason: [ERROR] : -[TiUIViewProxy hostingController]: unrecognized selector sent to instance 0x7ffadb0d2000 [ERROR] : Stack trace: [ERROR] : 0 CoreFoundation 0x000000010b40129b __exceptionPreprocess + 331 [ERROR] : 1 libobjc.A.dylib 0x000000010a1c6735 objc_exception_throw + 48 [ERROR] : 2 CoreFoundation 0x000000010b41ffa4 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132 [ERROR] : 3 CoreFoundation 0x000000010b405fb6 ___forwarding___ + 1446 [ERROR] : 4 CoreFoundation 0x000000010b407e88 _CF_forwarding_prep_0 + 120 [ERROR] : 5 0x00000001047dc5b0 -[TiUITabProxy handleWillShowViewController:animated:] + 80 [ERROR] : 6 0x00000001047dc435 -[TiUITabProxy navigationController:willShowViewController:animated:] + 101 [ERROR] : 7 UIKitCore 0x0000000118ccbfc4 -[UINavigationController _startCustomTransition:] + 1280 [ERROR] : 8 UIKitCore 0x0000000118ce27bc -[UINavigationController _startDeferredTransitionIfNeeded:] + 741 [ERROR] : 9 UIKitCore 0x0000000118ce3bac -[UINavigationController __viewWillLayoutSubviews] + 150 [ERROR] : 10 UIKitCore 0x0000000118c6f63f -[UILayoutContainerView layoutSubviews] + 217 [ERROR] : 11 UIKitCore 0x0000000119110015 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1441 [ERROR] : 12 QuartzCore 0x000000010888ed3d -[CALayer layoutSublayers] + 175 [ERROR] : 13 QuartzCore 0x0000000108893bf7 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 395 [ERROR] : 14 QuartzCore 0x000000010880caa6 _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 342 [ERROR] : 15 QuartzCore 0x0000000108843c2a _ZN2CA11Transaction6commitEv + 576 [ERROR] : 16 QuartzCore 0x00000001088449a6 _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv + 76 [ERROR] : 17 CoreFoundation 0x000000010b364037 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 [ERROR] : 18 CoreFoundation 0x000000010b35e4ce __CFRunLoopDoObservers + 430 [ERROR] : 19 CoreFoundation 0x000000010b35eb61 __CFRunLoopRun + 1537 [ERROR] : 20 CoreFoundation 0x000000010b35e221 CFRunLoopRunSpecific + 625 [ERROR] : 21 GraphicsServices 0x000000010fa121dd GSEventRunModal + 62 [ERROR] : 22 UIKitCore 0x00000001189f7115 UIApplicationMain + 140 [ERROR] : 23 0x0000000104761996 main + 102 [ERROR] : 24 libdyld.dylib 0x000000010d6d2551 start + 1 -- End simulator log ---------------------------------------------------------Thanks for all hard work guys but new version did not resolve my error totally, Now it is not crashing anymore but it is still freeze on random screen and also I am not using hyperloop module anywhere in my iOS app so before if I enable hyperloop I ws getting some errors, Without enabling hyperloop it was working fine but now without enabling hyperloop I am getting same errors only on ios 12
I'm also experiencing frequent, random app freezing now. Before the SDK fix, I would experience an immediate crash on app launch. That crashing has been resolved (on my end), however, a few different app interactions are now causing app freezes (no crash, no log). This could be from a button click (to call an HTTP request), adding or removing views, showing a NavigationWindow (modals), etc. — Since there is no error log output, I'm afraid I cannot provide much more, I just wanted to share my experience with the latest 7_4_X patched SDK (on iOS 12). — Thanks again for all of the great work & effort being put into these fixes! · Jason
OK, this issue is still not completely resolved from my perspective. The number of freezes changed from frequent to sporadic, but the issue isn't completely gone. The freezes do not occur when disabling the use of the JSCore framework.
For those who are still facing issue- Can you please share your test case with which we can reproduce the bug. It will help us debugging and will help us finding if the issue is same as mentioned in this ticket or different. Or if you can share your app to my email vsingh@axway.com so that we can debug. Thanks!
Apart from reproducible test cases, crash logs with stack traces would also be a tremendous help to narrow down the cause of any remaining issues. Please connect your device and check in Xcode under the Devices and Simulators window. There is a button to open a list of recent device logs which should include the crash log for your app. If they don't show up make sure to sync your device with iTunes because if there are more than 25 crash logs on your device, no new crash logs will be created.
This is still an issue on our production apps. We are noticing random freezes and crashes when trying to authenticate using a webview. We have shared a sample app that reproduces this issue in Case# 01006092 / iOS 12 App Crash With Xcode 10.0 Appc SDK 7.4 Should this ticket be reopened or are you guys fixing this as a separate Jira issue?
First of, thanks for all the feedback which showed os that we got the root cause of the issue! Still, there seem to be a few edge cases that our current fix does not cover. We are currently working on an improved version of the fix. This will also address a regression introduced with the fix where some event listeners are not properly fired thus giving the impression of app freezes because it suddenly stops its usual workflow. As soon as it is ready we'll let you know!
Thanks for the update @Jan Vennemann
PR: https://github.com/appcelerator/titanium_mobile/pull/10370 SDK Download: https://www.dropbox.com/s/tnj6om696g4llf2/mobilesdk-7.4.1.v20181004162821-osx.zip?dl=0 An updated version of the fix is currently under review. It fixes a regression where some events were not properly fired anymore. Please use the above download link until the PR is merged and can be installed via CLI from the 7_4_X branch. If you continue to see issues you think are related to this please let us know. You can send crash reports, reproducible test cases or even your app project to either ([mailto:jvennemann@axway.com] or [mailto:vsingh@axway.com].
I don't have app freezing and crashing issues any more Without using
[~ppancholi] We have deprecated 'kroll-thread' and 'ticore' and have to remove from SDK 8.0.0. So we have to fix all issue related with 'main-thread' and 'jscore'. If you can share your reproducible test case or app project with us, would be great. It will help us to find the edge cases which is still not handled. Thanks!
I have shared app project zip on vsingh@axway.com, jvennemann@axway.com from dropbox with in detail messages regarding App functionality and error, Please check and let me know but we need to resolve this as soon as possible because current app in app store is crashing on iOS 12 and new SDK solved crushing and Freezing problem but with this issue we can not do new release
We just started testing with the latest 7_4_X branch with jscore and run-on-main-thread both true. It mostly freezes now on startup. It's easy to reproduce...just keep removing your app from the multi-task bar and then re-opening. It will freeze half the time. We make several network calls on startup and I think this is a big part of the issue that causes the main ui thread to freeze up and become unresponsive. We really need a fix for this asap.
Okay this is very interesting...if we remove the AppC generated code in Alloy.js for logging into ACS we no longer get the freeze on startup.
[~ppancholi], after a quick check of your submitted project it looks like you are experiencing issues with notifications. Please open a dedicated ticket for that as the scope of this tickets are solely the crashes in JSC. Describe in detail what steps to take to reproduce your issue, what is the actual behavior and what should be the expected behavior. [~btknorr], testing with a sample Alloy app does not crash/freeze for us, so it is probably a combination of things. Again, please provide reproducible test cases with as much information as possible or submit your project to help us narrow down any remaining issues and if they are related to the initial JSC crash reported here. Thanks!
Jan - please be sure you are testing on actual devices and not the simulator. Also the freeze happens much more often on older iPhones like the 6 and 7. Unfortunately we cannot submit any of our client's proprietary apps. Also there are no stack traces when the app freezes...it just becomes unresponsive to any interactions.
I'm testing on an iPhone 6s Plus and was able to reproduce all previous crashes there. However, i have not yet seen an actual app freeze yet, only crashes. Other reported "freezes" where due to events not being fired properly and thus the app appearing to be frozen. If you don't mind please ask your clients if you are allowed to share code with Axway to investigate the issues. The project will only be used by our engineers for the sole purpose of identifying any remaining edge cases for iOS 12 issues. We really want to help you guys, but as the issues seems to mostly appear in real life app projects with many moving parts working together we dependent on you providing us with test cases/projects to work with.
Now that we are past the startup freeze, we are now seeing freezes just by using app after some time. Seems directly related to making an http call to get data and updating the UI. Also we don't get crashes...only freezes.
@jvennemann I am having this issue with 7.4.1 and all new sdk only, If you try with 7.2.0 It is not happening, and Without using 7.4.1 my app is crashing and freezing so it has something to do with this new update only, as I am converting push messages to alert when app is open, Everything is working fine with until I update SDK apart from crash and freeze in ios 12, I will generate separate ticket for this
[~ppancholi], this ticket deals with crashes and freezes under iOS 12 only and your issue seems to be neither a crash nor a freeze. We can't deal with all 7.4.0 issues in only one ticket, this gets confusing real quick. Please open a new ticket describing in detail what your issue is and mention me in the comments. I'll move it to TIMOB and investigate as soon as i can. // EDIT: Sorry it was early in the morning and i didn't see your last sentence that you will create a new ticket. Thanks a lot for helping us organize the issues related to 7.4.0 ;)
Just to echo @Brian Knorr. While the latest nightly is much improved, I am still getting crashes and freezes. Unfortunately I also have highly secure financial and telecommunications apps that I can't share the source. I have been trying to create simple apps to replicate the issues unsuccessfully. Much like Brian, these apps have live feeds and/or many concurrent api calls that update the UI. It is during or after api calls that I am (guessing) are the cause. (Stack traces don't help much.) This might help... I have found Titanium on iOS 12 more "fragile". One fix I applied was related to an issue that during a window transition, I updated the UI (modifying a TableViewSection) and triggered API calls to refresh the UI content. The crash occurred when that sequence was performed about three times. To fix I simply added a delay of 200ms before making the API calls (I think the time for the animation to complete). I had applied a similar fix to Android to fix a crash that was occurring under these conditions previously.
Due to lack of test cases we currently are having a hard time to further investigate this. To move forward i created a special 7.4.1 build which includes a ton of debugging output. Please run your app with this build and send me the log output along with a possible crash report to [mailto:jvennemann@axway.com]. Please also add as much debug info to your app as well, especially to callbacks of your HTTP requests or other event handlers so we have a rough idea where in your app the crash or freeze happened. Valuable information is the proxy and event name of callback functions. Download SDK with debug logging: https://www.dropbox.com/s/u0kh1w7gtk99gk0/mobilesdk-7.4.1-debug.zip?dl=0
[ERROR] : ** BUILD FAILED ** [ERROR] : The following build commands failed: [ERROR] : CompileC /Users/ppancholi/Documents/Appcelerator_Studio_Workspace/app-ios/build/iphone/build/Intermediates/Bramalea\ City\ Centre.build/Debug-iphoneos/Bramalea\ City\ Centre.build/Objects-normal/armv7/KrollObject.o /Users/ppancholi/Documents/Appcelerator_Studio_Workspace/app-ios/build/iphone/Classes/KrollObject.m normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler [ERROR] : (1 failure) With new sdk from dropbox, I am getting this compilation error on KrollObject, I am not sure if it is helpful to you
Sorry, there was a mixup with the download links. Updated the link in my comment above!
With the latest 7.4.1.v20181004162821 build, I get the following if we enable hyperloop. An uncaught exception was thrown! Invalid Version: 12.-1.0 Invalid Version: 12.-1.0 I tried then adding in hyperloop 3.1.3 which did let me build to the simulator but upon then trying to build to a device I get the following: ** BUILD FAILED **
I updated the debug build with more logs. You can get the new version here: https://www.dropbox.com/s/uwtzqmfwxtt2br0/mobilesdk-7.4.1-debug.zip?dl=0 [~TaylorThompson], do a full clean by deleting the
buildfolder when switching between versions. If the issue persists, please open a new ticket for issues other than crashes related to JSC or freezes. If you do, please also enabled trace logging with-l traceand post the full logs, since just a simple "BUILD FAILED" does not help us in identifying the problem.If it fails when compiling to the device with only "BUILD FAILED" check your tiapp.xml that you have the correct app
@Jan Venneman, that build helps. It helped to catch one crash that the previous sdks didn't present. Basically the cause in this one case was updating the contents of a
TableViewRowthat had been removed from the table, yet the reverence was still held with JS (on the alloy$). The crash was aEXC_BAD_ACCESS. It looks like the ObjC objects were freed from memory despite existing JS references to them. I have worked around that crash, but you might want to look at it anyway. It would be good to have this "trace" logging as a feature going in future sdks. I will continue working to with this debug sdk for the other crashes and freezes.@Jan Venneman - I have been running this DEBUG SDK the whole week last week, today it crashed for the first time on startup - I sent you a crash log via email. Thanks
Gonna test with this debug release and let you guys know! Thanks for sharing
Hi all, Thanks for all the effort to get to the bottom of it. Most people have good results, and working with JS Core disabled provides a work-around. However I am still getting freezes on an actual ipad (not simulated) with JS Core enabled. Mostly when I am doing an action that takes many REST Requests (it's ecom) login, getbaskets, get wishlists, load adresses etc. I am happy to provide the App code somewhere privately, but maybe [these log](https://drive.google.com/file/d/10FpdKH9IiN3JwDDIYMtnGqKlncCtks-B/view?usp=sharing) files traced with the debug SDK help already. Thanks Holger
[~hnestmann], thanks for the feedback Holger. I've contacted you via email regarding your app project.
I got this problem too.
Hey guys, we are changing the status of this ticket to resolved for the upcoming 7.4.1 GA release. This is required for our internal JIRA workflow. We are fully aware that some of you still have issues so we will keep this issue open (with state resolved, but not closed yet). The initial crash we could reproduce was solved and we are actively working together with some of you to reproduce other issues like the freezes. Once we have more insight on those the ticket will be put back into "In progress" state. Sorry in advance for the inconvenience and unnecessary mails this might cause.
@Jan Vennemann. Thank for the heads up! In our case, we can't replicate as we get random crashes, always related to jscore not being able to launch a new code block. Most probably a closure/block got deallocated. Always happening when doing lots of HTTP requests and showing data in ListViews. Something like this:
Thread 3 Crashed:: KrollContext<kroll$1> 0 com.apple.JavaScriptCore 0x00000001029ca9d2 JSC::ScriptExecutable::newCodeBlockFor(JSC::CodeSpecializationKind, JSC::JSFunction*, JSC::JSScope*, JSC::JSObject*&) + 82 1 com.apple.JavaScriptCore 0x00000001029cba2b JSC::ScriptExecutable::prepareForExecutionImpl(JSC::VM&, JSC::JSFunction*, JSC::JSScope*, JSC::CodeSpecializationKind, JSC::CodeBlock*&) + 219 2 com.apple.JavaScriptCore 0x0000000102709195 JSC::LLInt::setUpCall(JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 773 3 com.apple.JavaScriptCore 0x0000000102148025 llint_entry + 26699 4 com.apple.JavaScriptCore 0x0000000102141665 vmEntryToJavaScript + 235 5 com.apple.JavaScriptCore 0x000000010263d106 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 470 6 com.apple.JavaScriptCore 0x000000010283e5a1 JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 177 7 com.apple.JavaScriptCore 0x0000000102180e94 JSObjectCallAsFunction + 468 8 net.teamworkpm.phone 0x0000000100793b43 TiBindingEventProcess + 947 (TiBindingEvent.m:269) 9 net.teamworkpm.phone 0x0000000100793dd8 -[TiBindingCallbackInvoke invoke:] + 56 (TiBindingRunLoop.m:51) 10 net.teamworkpm.phone 0x0000000100528a03 -[KrollContext invoke:] + 163 (KrollContext.m:985) 11 net.teamworkpm.phone 0x0000000100529edb -[KrollContext main] + 3563 (KrollContext.m:1350) 12 com.apple.Foundation 0x000000010411d932 __NSThread__start__ + 1221 13 libsystem_pthread.dylib 0x0000000109af7661 _pthread_body + 340 14 libsystem_pthread.dylib 0x0000000109af750d _pthread_start + 377 15 libsystem_pthread.dylib 0x0000000109af6bf9 thread_start + 13The same freeze issue here. Throughout normal testing on iOS, the app intermittently freezes and I have to quit/restart the app. This has been happening consistently for the past 2-3 weeks. Got a lot better upgrading to 7.4.1 but still happens from time to time. Had the run-on-main-thread set to true. The freeze/crash happens randomly on various screens, but the majority of the freezes happen when transitioning between screens. I've seen this consistently on iOS, but not once on Android.
Can we get this issue re-opened or create a new one? Doesn't make sense that the status is Resolved and Fixed, when it's not.
*Update:* I posed a few weeks back & just wanted to note that my current experience is greatly similar to that of @Kai Lu. — Frequent freezing in TiSDK 7.4.0+ / slightly less freezing in TiSDK 7.4.1+ — iOS is my primary focus, so I cannot report on Android.
<property name="run-on-main-thread" type="bool">true</property> <use-jscore-framework>true</use-jscore-framework>First off, thanks for all the feedback. As promised i reopened the issue. However we still have a hard time reproducing this issue. As some of you already wrote these freezes are most likely due to optimization and changes to the internals in Apple's JavaScriptCore, especially GC handling. When you are experiencing freezes, will iOS terminate the app after you wait for ~10 sec? If so, please look for crash reports on your device and post them here. We are also still looking for app projects to reproduce the freezes so we can do some actual debugging on that. If you can share your project with us please send it to [mailto:jvennemann@axway.com] or [mailto:vsingh@axway.com]. All code is considered private and confidential of course and will only be used for the purpose of helping us debug the freeze issue. Last but not least: If you are using timers in your app and experience freezes please check this build which contains a minor change to how timer callbacks are executed to prevent possible thread deadlocks. https://www.dropbox.com/s/zasd5dd7j9xl7lx/mobilesdk-7.4.2-osx.zip?dl=0
Hi Jan, Really appreciate your quick response. We do have a timer in the background constantly checking with the database sync. Will test on 7.4.2 to see if that helps with the freezes. Thanks, Kai
Just tried 7.4.2 but unfortunately the freeze issue is still happening and by digging into the log I could not find a pattern as to where in the code it freezes (seems pretty random to me) but it all happened when I open a new window. We are currently in the beta testing stage with a critical product release in coming.. you know we were going to choose a different tool and we chose you because you can get this stuff done and will evolve.. but it's holding up our business at this point so a quick fix of this freeze issue is MOST appreciated.
Apologies if this is noise. But due to release time lines, we have reverted to
100% agree with @dbankier - we have had to release our apps with jscore disabled and have had no issue since, so ideally we must ensure that this functionality is not deprecated until such time as the jscore implementation is robust.
Thanks David for the solution. I can verify it is working a lot better now. Definitely agree with David and Greg on keeping the non-jscore without deprecation. So much more stable and even faster than Apple's JS engine.
Thank you for the continued efforts, Jan! We're currently using Hyperloop (and plan to extend that use) in our current project. *Question:* Does Hyperloop require (JavaScriptCore)? — I gather it does. — If so, we don't really have the option to disable it, even as a temporary solution like some of the devs above suggest. Any additional thoughts?
I have also had to use
@Leonardo - did you try the 7.4.2 build as described above by Jan? It has some changes to optimise timer callbacks etc which might help you. I am still testing, but it seems to have reduced issues for me so far... https://www.dropbox.com/s/zasd5dd7j9xl7lx/mobilesdk-7.4.2-osx.zip?dl=0
Alright guys, here is another update for you. We replaced our timer handling in jscore with native timers and it looks very promising. First tests with various projects proved positive results and the app freezes were gone. To get more feedback we would like to ask you once more to test with the following new build: https://www.dropbox.com/s/80bqt55221yqeiu/mobilesdk-7.5.0-osx.zip?dl=0 Especially if you are having
run-on-main-threadset to false since we couldn't verify this yet in a project that reproduces the freezes.@Jan - is the timer handling much different from the 7.4.2 build you gave us recently?
[~mdelmarter], yes! Actually, it's a complete rewrite replacing the old timers when using JSCore.
Jan Vennemann? Do I need to make any config changes in order to make my project run with 7.5.0? Right now when I try to build, I get the following error: [INFO] : Invoking xcodebuild [ERROR] : ** BUILD FAILED ** [ERROR] : The following build commands failed: [ERROR] : Ld /Users/xxx/Titanium_Studio_Workspace/spacious-mobile-alloys/build/iphone/build/Intermediates/XXXXbuild/Debug-iphoneos/XXXX.build/Objects-normal/armv7/XXXX normal armv7 [ERROR] : (1 failure)
No, you shouldn't have to change anything. Please post logs with at least debug log level so we can see what is going on.
Hey Jan, I haven't done any _extensive_ testing with 7.5.0, however, it does seem to greatly improve the stability of my current app which was freezing consistently with 7.4.X. Thank you for the continued effort on this issue! — I'm going to keep testing w/7.5.0 moving forward. I'll stay tuned into this ticket & report any buggy activity. =] · Jason
Hi Jan, is there a way we can add the latest changes to 7.4.1 ? As 7.5.0 has so many other changes we would really like to just fix this issue with our current app setup. Is there a specific commit or pull we can cherry pick on top of 7.4.1 to take advantage of the latest changes?
When I install 7.5.0 and use...I get this message and the app doesn't start up [WARN] The implicit global scope for variable declarations in app.js is deprecated in 7.5.0, and will be removed in 9.0.0 [ERROR] Script Error Module "app.js" failed to leave a valid exports object ANY IDEAS
@Peter Ladis, could be an uninitialize global variable like:
var myVar;@Peter : Are you 'polluting the global scope' with
Ti.App.my_custom_thingin app.js ? I _think_ this is what the deprecation refers to. It's been discouraged for a while, since I _think_ it causes issues with memory garbage collection.There is a known issue currently in 7.5.0 that causes problems if you use third-party modules and assign them using the
nsattribute in your Alloy templates instead of using the recommendedmoduleattribute. I'll prepare a backport of the timer changes for a 7.4.2 build so you can exclusively test those changes and will share it with you here once it's ready.So I have code like this in my app.js function include(file) { return eval(Ti.Filesystem.getFile(Ti.Filesystem.resourcesDirectory, file).read().text); } and then below...I bring in the moment.js class like this include('ui/common/moment.js'); But for some reason getting initialization errors like this: [ERROR] Script Error { [ERROR] column = 16; [ERROR] line = 306; [ERROR] message = "Can't find variable: moment"; Is this method not allowed in 7.5.0 The FULL STACK [ERROR] Script Error { [ERROR] column = 16; [ERROR] line = 306; [ERROR] message = "Can't find variable: moment"; [ERROR] sourceURL = "file:///Users/peterladis/Library/Developer/CoreSimulator/Devices/C8447ECB-B089-4017-9E19-CB8E5F56C43E/data/Containers/Bundle/Application/9AD7E62C-1478-4BBB-8EEB-9B6378050252/LilyPad.app/ui/lib/ScrollView.js"; [ERROR] stack = " at formatDate(/ui/lib/ScrollView.js:306:16)\n at buildActIndicator(/ui/lib/ScrollView.js:199:39)\n at ScrollView(/ui/lib/ScrollView.js:311:20)\n at FeedList(/ui/handheld/iphoneV2/FeedTemplates/FeedList.js:16:31)\n at Home(/ui/handheld/iphoneV2/ContentWindows/Home.js:110:28)\n at createCenterNavWindow(/ui/handheld/iphoneV2/FirstViewV2.js:2535:25)\n at FirstViewV2(/ui/handheld/iphoneV2/FirstViewV2.js:7460:40)\n at ApplicationWindow(/ui/handheld/iphoneV2/ApplicationWindow.js:23:30)\n at (/app.js:162:26)\n at (/app.js:205:3)\n at global code(/app.js:207:70)\n at require@[native code]\n at (/ti.main.js:27:10)\n at loadAsync(/ti.internal/bootstrap.loader.js:106:11)\n at global code(/ti.main.js:24:52)"; [ERROR] toJSON = "
@Jan Vennemann I installed your 7.5.0 (thanks!) and reverted that 'unarchiveFromTemplate' method in TiViewProxy.m back to the one in 7.4.1.GA (because my app uses some 3rd party modules like you mention, also see: https://github.com/appcelerator/titanium_mobile/pull/10131) and my app has been without freeze for two hours now while using it 'extensively'. With 7.4.1.GA it would freeze within 5 to 15 minutes. (edit) Forget to mention: running with use-jscore-framework and run-on-main-thread both turned on.
@Jan.....Thanks ill wait for 7.4.2 build with the freeze fixes
> I'll prepare a backport of the timer changes for a 7.4.2 build so you can exclusively test those changes and will share it with you here once it's ready. @Jan Vennemann I'd also love the 7.4.2 backport and will try it out and give feedback right away (we'll have ~30 people test it). We're in a [bit of trouble](https://gymhero.me/community/t/version-2-24-released/2683) because of this bug, and I'd love to submit an update as soon as possible :)
Hi, @Jan thank you for https://www.dropbox.com/s/zasd5dd7j9xl7lx/mobilesdk-7.4.2-osx.zip?dl=0 it works for me with jscore and main thread turned on. I was in trouble to extract and use 7.4.2 SDK from zip, so I just extracted folder "iphone" over my 7.4.1.GA and no freezes or crashes now in my app. Great job! And I also wait for backport to 7.4.2
Which build is good to go for freezing issues....the older 7.4.2 did not fix anything?
@sergey.....is that build a new 7.4.2. or one from the other day with problems still
Any update on this?
Sorry, it took a little longer. We detected an issue when run-on-main-thread is set to false and had to disable the new timer implementation for that. Now, i updated the 7.4.2 build i shared earlier to the newest version. Here is the download link again: https://www.dropbox.com/s/zasd5dd7j9xl7lx/mobilesdk-7.4.2-osx.zip?dl=0 To enable the new timer implementation it is required to use js core (enabled by default or explicitly via
<use-jscore-framework>true</use-jscore-framework>underios) and run on main thread also set to true with<property name="run-on-main-thread" type="bool">true</property>. We also included the change from the earlier 7.4.2 to timers when not using main thread which proved to help for some of you.@Jan Vennemann - will you guys be able to just release the new timer fixes as part of 7.4.2.GA rather than part of 7.5.0? 7.5.0 has many other changes that many apps might require alot of work to get working (including ours) and if this fix could be released as part of 7.4.2.GA that would be great as it would mean most people could simply update from 7.4.0 / 7.4.1 to 7.4.2 without any real work to their apps.
+1 on David's suggestion. Priority is getting a stable SDK that fixes this issue. I am not even sure what is in 7.5.0 to ensure that other areas are working - will tackle that when we get the formal Release Notes etc. Thanks again for the great work team. Initial feedback from my beta testers is that everything is much more stable with zero app freezing.
The above 7.4.2 is basically what you are asking for. An updated 7.4.1 with only the timer fixes. I'm not sure if we can squeeze in an official 7.4.2 release because the GA process takes time and resources are already reserved for 7.5.0 and 8.0.0. However, we'll discuss this internally and see what we can do. [~dieskim], why would the changes in TIMOB-24909 cause a few days work? Not overly familiar with that ticket, but shouldn't the implementation be 100% backward compatible?
@Jan Vennemann thanks for the info. Do you have a specific branch on your fork of titanium_mobile on GitHub that is the 7.4.2 version? That way we could use that 7.4.2 and build cherry pick other fixed we need etc on top of that as needed. It should be good enough for people to build their own sdk versions and get apps out there. Maybe you already have a branch I could not find or maybe you can create a 7.4.2 branch? Thanks for all the hard work on this. I'll build our apps with 7.4.2 tomorrow and let you know how it goes.
In iOS 11, this 7.4.2 did help with a lot of crashes in our app. We get 1 crash, after allowing permissions to push notifications, but after that the app doesn't crash. Push notifications do not seem to be working still in iOS 11.
Question on 7.4.2 was there any change to the modules or can we just drop the sdk mobilesdk folder?
We also could use a 7.4.2 branch with timer fixes applied rather than these only going into 7.5.0. We need to rebuild the 7.4.2 SDK with our fixes applied (and the new timer fixes) so could use a branch with a commit to cherry-pick on top of 7_4_X. Looked in master and 7_4_X and 7_5_X but couldn't see a commit that matched the native timer fixes that stopped the app hanging. Thanks... these hangs are causing major problems for our customers.
The PR with the new timer implementation is still under review and testing, so it is not merged into any of the main branches yet. [~dieskim] and everyone else asking for 7_4_X branch line, here you go: [timer-refactor-7_4_X](https://github.com/janvennemann/titanium_mobile/tree/timer-refactor-7_4_X). This is the branch used in [this](https://github.com/appcelerator/titanium_mobile/pull/10416) 7_4_X PR i just opened. [~amigoni], the 7.4.2 build has no other changes, you can just drop the sdk into your mobilesdk folder.
@Jan Vennemann thank you so much. That's perfect. I can confirm that this 7.4.2 build is much better for us, but it is not completely bug free yet. Our app ran for 30 minutes with aggressive usage and testing and then crashed. The crash was once again cause by setting and accessing objects via Hyperloop, exactly as before but it did last longer. Jan it's the same crash as before in the emails I sent you but the app did last alot longer this time. I will work with our tester tomorrow to see if we can reproduce
Glad to hear that it's working for you. Please open a new ticket regarding the Hyperloop issue with all relevant information so we can then investigate what's going on in that new ticket.
The new timer implementation is now merged to all our main branch lines! Just to let you know we plan to put out a 7.4.2.GA to bring just the timer fixes to 7.4.X. It will be released alongside 7.5.0.GA.
I tested my app on 7.4.2 after installing it : appc ti sdk install --branch 7_4_X 7.4.2.v20181101134650 and still the app freezed suddenly at point and then app crashed. Regards Jatin
And crash didn't generated any error logs. Regards Jatin
Tested the app with : appc ti sdk install --branch 7_5_X 7.5.0.v20181101101355 and that crashes as well. Regards Jatin
[~mr.jatinjoshi.mca@gmail.com], please make sure you are using JSCore and have run-on-main-thread enabled. If a crash occurs make sure to get the related crash report from the device. Also provide the logs and as much other information as possible. We can't do much with "it crashed" and no other information at all.
Dear @Jan, here's a big thank you for your efforts and especially communicating so well and putting out SDK builds that we can test and use right away, without having to wait for an SDK release. https://media.giphy.com/media/bKBM7H63PIykM/giphy.gif
*Dear @Jan,* I tested my app on 7.4.2 after installing it : appc ti sdk install --branch 7_4_X 7.4.2.v20181101134650 and still the app freezed suddenly at point and then app crashed. I have enabled the two properties as you mentioned:
The Crashes freeze seems to have gone down drastically on the https://www.dropbox.com/s/zasd5dd7j9xl7lx/mobilesdk-7.4.2-osx.zip?dl=0 SDK and I'm using it on production with:
With SDK 7.5.0.v20181102122228 and SDK 7.4.2.v20181101134650 our app now runs fine on iOS 12.x, 11.x and 10.x, but crashes shortly after every startup (on both device and simulator) on iOS 9.x and iOS 8.x: [ERROR] : The application has crashed with an uncaught exception 'NSInvalidArgumentException'. [ERROR] : Reason: [ERROR] : +[NSTimer scheduledTimerWithTimeInterval:repeats:block:]: unrecognized selector sent to class 0x10c4a3e38 [ERROR] : Stack trace: [ERROR] : 0 CoreFoundation 0x000000010c281e65 __exceptionPreprocess + 165 [ERROR] : 1 libobjc.A.dylib 0x000000010b897deb objc_exception_throw + 48 [ERROR] : 2 CoreFoundation 0x000000010c28a38d +[NSObject(NSObject) doesNotRecognizeSelector:] + 205 [ERROR] : 3 CoreFoundation 0x000000010c1d790a ___forwarding___ + 970 [ERROR] : 4 CoreFoundation 0x000000010c1d74b8 _CF_forwarding_prep_0 + 120 [ERROR] : *{color:red}5 --------- 0x000000010636bf5b -[KrollTimerManager setIntervalFromArguments:shouldRepeat:] + 475{color}* [ERROR] : 6 --------- 0x000000010636b975 __35-[KrollTimerManager initInContext:]_block_invoke.298 + 69 [ERROR] : 7 CoreFoundation 0x000000010c1701cc __invoking___ + 140 [ERROR] : 8 CoreFoundation 0x000000010c17001e -[NSInvocation invoke] + 286 [ERROR] : 9 JavaScriptCore 0x0000000106e15533 _ZN3JSC24ObjCCallbackFunctionImpl4callEP9JSContextP13OpaqueJSValuemPKPKS3_PS6_ + 451 [ERROR] : 10 JavaScriptCore 0x0000000106e150a6 _ZN3JSCL34objCCallbackFunctionCallAsFunctionEPK15OpaqueJSContextP13OpaqueJSValueS4_mPKPKS3_PS6_ + 262 [ERROR] : 11 JavaScriptCore 0x0000000106e1632d _ZN3JSC19APICallbackFunction4callINS_20ObjCCallbackFunctionEEExPNS_9ExecStateE + 573 [ERROR] : 12 JavaScriptCore 0x0000000106de03b0 _ZN3JSC5LLInt9setUpCallEPNS_9ExecStateEPNS_11InstructionENS_22CodeSpecializationKindENS_7JSValueEPNS_17LLIntCallLinkInfoE + 528 [ERROR] : 13 JavaScriptCore 0x0000000106de73cd llint_entry + 22900 [ERROR] : 14 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 15 ??? 0x00000198e0ba8c3a 0x0 + 1756116978746 [ERROR] : 16 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 17 JavaScriptCore 0x0000000106de736d llint_entry + 22804 [ERROR] : 18 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 19 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 20 JavaScriptCore 0x0000000106de736d llint_entry + 22804 [ERROR] : 21 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 22 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 23 JavaScriptCore 0x0000000106de736d llint_entry + 22804 [ERROR] : 24 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 25 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 26 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 27 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 28 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 29 JavaScriptCore 0x0000000106de1849 vmEntryToJavaScript + 326 [ERROR] : 30 JavaScriptCore 0x0000000106cb4ee9 _ZN3JSC7JITCode7executeEPNS_2VMEPNS_14ProtoCallFrameE + 169 [ERROR] : 31 JavaScriptCore 0x0000000106c9b7f4 _ZN3JSC11Interpreter7executeEPNS_17ProgramExecutableEPNS_9ExecStateEPNS_8JSObjectE + 10404 [ERROR] : 32 JavaScriptCore 0x0000000106aa54b6 _ZN3JSC8evaluateEPNS_9ExecStateERKNS_10SourceCodeENS_7JSValueERN3WTF8NakedPtrINS_9ExceptionEEE + 470 [ERROR] : 33 JavaScriptCore 0x0000000106cfa548 JSEvaluateScript + 424 [ERROR] : 34 --------- 0x0000000106367847 -[KrollEval jsInvokeInContext:exception:] + 263 [ERROR] : 35 --------- 0x0000000106363199 -[KrollBridge loadCommonJSModule:withSourceURL:] + 409 [ERROR] : 36 --------- 0x00000001063640e2 -[KrollBridge loadJavascriptText:fromFile:withContext:] + 98 [ERROR] : 37 --------- 0x000000010636436c -[KrollBridge cachedLoadAsFile:asJSON:withContext:] + 268 [ERROR] : 38 --------- 0x000000010636449c -[KrollBridge loadAsFile:withContext:] + 268 [ERROR] : 39 --------- 0x00000001063647e2 -[KrollBridge loadAsFileOrDirectory:withContext:] + 82 [ERROR] : 40 --------- 0x0000000106365145 -[KrollBridge require:path:] + 949 [ERROR] : 41 --------- 0x000000010636920b CommonJSRequireCallback + 187 [ERROR] : 42 JavaScriptCore 0x0000000106cfbbab _ZN3JSC19APICallbackFunction4callINS_18JSCallbackFunctionEEExPNS_9ExecStateE + 571 [ERROR] : 43 JavaScriptCore 0x0000000106de03b0 _ZN3JSC5LLInt9setUpCallEPNS_9ExecStateEPNS_11InstructionENS_22CodeSpecializationKindENS_7JSValueEPNS_17LLIntCallLinkInfoE + 528 [ERROR] : 44 JavaScriptCore 0x0000000106de73cd llint_entry + 22900 [ERROR] : 45 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 46 JavaScriptCore 0x0000000106de73d8 llint_entry + 22911 [ERROR] : 47 JavaScriptCore 0x0000000106de1849 vmEntryToJavaScript + 326 [ERROR] : 48 JavaScriptCore 0x0000000106cb4ee9 _ZN3JSC7JITCode7executeEPNS_2VMEPNS_14ProtoCallFrameE + 169 [ERROR] : 49 JavaScriptCore 0x0000000106c9b7f4 _ZN3JSC11Interpreter7executeEPNS_17ProgramExecutableEPNS_9ExecStateEPNS_8JSObjectE + 10404 [ERROR] : 50 JavaScriptCore 0x0000000106aa54b6 _ZN3JSC8evaluateEPNS_9ExecStateERKNS_10SourceCodeENS_7JSValueERN3WTF8NakedPtrINS_9ExceptionEEE + 470 [ERROR] : 51 JavaScriptCore 0x0000000106cfa548 JSEvaluateScript + 424 [ERROR] : 52 --------- 0x00000001063616d2 -[KrollBridge evalFileOnThread:context:] + 1314 [ERROR] : 53 --------- 0x000000010636722c -[KrollInvocation invoke:] + 124 [ERROR] : 54 --------- 0x00000001063684b3 -[KrollContext invoke:] + 163 [ERROR] : 55 --------- 0x0000000106368879 -[KrollContext invokeOnThread:method:withObject:callback:selector:] + 169 [ERROR] : 56 --------- 0x0000000106361854 -[KrollBridge evalFile:callback:selector:] + 116 [ERROR] : 57 --------- 0x00000001063627f7 -[KrollBridge didStartNewContext:] + 2935 [ERROR] : 58 --------- 0x000000010636912f -[KrollContext main] + 1775 [ERROR] : 59 --------- 0x0000000106368287 __21-[KrollContext start]_block_invoke + 39 [ERROR] : 60 libdispatch.dylib 0x000000010d09fd59 _dispatch_call_block_and_release + 12 [ERROR] : 61 libdispatch.dylib 0x000000010d0bb4a7 _dispatch_client_callout + 8 [ERROR] : 62 libdispatch.dylib 0x000000010d0a5f2d _dispatch_main_queue_callback_4CF + 714 [ERROR] : 63 CoreFoundation 0x000000010c1e1d09 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 [ERROR] : 64 CoreFoundation 0x000000010c1a32c9 __CFRunLoopRun + 2073 [ERROR] : 65 CoreFoundation 0x000000010c1a2828 CFRunLoopRunSpecific + 488 [ERROR] : 66 GraphicsServices 0x000000010df1cad2 GSEventRunModal + 161 [ERROR] : 67 UIKit 0x0000000108959610 UIApplicationMain + 171 [ERROR] : 68 --------- 0x000000010634e683 main + 115 [ERROR] : 69 libdyld.dylib 0x000000010d0ea92d start + 1 [ERROR] : 70 ??? 0x0000000000000001 0x0 + 1
[~fahad86], check the updated 7.4.2 build: https://www.dropbox.com/s/zasd5dd7j9xl7lx/mobilesdk-7.4.2-osx.zip?dl=0 It improves memory management of timer callbacks and arguments for certain edge cases. [~mj], we are currently working on a compatibility fix for iOS <10
Hi Jan, We using device with OS Version: iPhone OS 12.0.1 (16A404). Crashes happening on iOS 12.x only. *No crashes on 11.x and 10.x* I tested my app on 7.4.2 after installing it : appc ti sdk install --branch 7_4_X 7.4.2.v20181101134650 and still the app freezed suddenly at point and then app crashed. I have enabled the two properties as you mentioned:
[~venkateshkumarg], you crash report is incomplete. Please connect your device to iTunes and sync it to fix the issue (1 Report of type '109(
Hi Jan, *Please check my updated full crash report:* [https://www.dropbox.com/s/rkvt63bizpjbsqm/Scalepoint-2018-11-08-171656.crash?dl=0] Incident Identifier: 667E8DBE-0C22-4083-A87B-1C9FB29D0DC9 CrashReporter Key: 987e82d3b7c6d177d5a5dcfb710d06e5db44f1f8 Hardware Model: iPad5,3 Process: Scalepoint [420] Path: /private/var/containers/Bundle/Application/8435F3FD-62E4-4F60-A8A2-F23083ACE5BF/Scalepoint.app/Scalepoint Identifier: com.scalepoint.ecbmobile Version: 2018110800 (3.2.3) Code Type: ARM-64 (Native) Role: Non UI Parent Process: launchd [1] Coalition: com.scalepoint.ecbmobile [536] Date/Time: 2018-11-08 17:16:56.1464 +0530 Launch Time: 2018-11-08 17:16:54.6949 +0530 OS Version: iPhone OS 12.1 (16B92) Baseband Version: n/a Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace OBJC, Code 0x1 Triggered by Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x0000000198afddf8 0x198adc000 + 138744 1 libsystem_kernel.dylib 0x0000000198af7838 0x198adc000 + 112696 2 libsystem_kernel.dylib 0x0000000198af77d4 0x198adc000 + 112596 3 libobjc.A.dylib 0x00000001981394b4 0x198133000 + 25780 4 libobjc.A.dylib 0x000000019813940c 0x198133000 + 25612 5 libobjc.A.dylib 0x0000000198144b0c 0x198133000 + 72460 6 libobjc.A.dylib 0x0000000198151098 0x198133000 + 123032 7 Scalepoint 0x000000010072a0e0 0x1006a0000 + 565472 8 libobjc.A.dylib 0x000000019815338c 0x198133000 + 131980 9 FrontBoardServices 0x000000019b9dbaa4 0x19b990000 + 309924 10 FrontBoardServices 0x000000019b9db728 0x19b990000 + 309032 11 FrontBoardServices 0x000000019b9dbd44 0x19b990000 + 310596 12 CoreFoundation 0x0000000198ef81cc 0x198e4c000 + 704972 13 CoreFoundation 0x0000000198ef814c 0x198e4c000 + 704844 14 CoreFoundation 0x0000000198ef7a30 0x198e4c000 + 703024 15 CoreFoundation 0x0000000198ef28fc 0x198e4c000 + 682236 16 CoreFoundation 0x0000000198ef21cc 0x198e4c000 + 680396 17 GraphicsServices 0x000000019b169584 0x19b15e000 + 46468 18 UIKitCore 0x00000001c5d2d054 0x1c5445000 + 9338964 19 Scalepoint 0x00000001006a7994 0x1006a0000 + 31124 20 libdyld.dylib 0x00000001989b2bb4 0x1989b2000 + 2996 Thread 1: 0 libsystem_pthread.dylib 0x0000000198b86ce8 0x198b78000 + 60648 Thread 2: 0 libsystem_pthread.dylib 0x0000000198b86ce8 0x198b78000 + 60648 Thread 3: 0 libsystem_pthread.dylib 0x0000000198b86ce8 0x198b78000 + 60648 Thread 4: 0 libsystem_pthread.dylib 0x0000000198b86ce8 0x198b78000 + 60648 Thread 5: 0 libsystem_pthread.dylib 0x0000000198b86ce8 0x198b78000 + 60648 Thread 6 name: com.apple.uikit.eventfetch-thread Thread 6: 0 libsystem_kernel.dylib 0x0000000198af3ed0 0x198adc000 + 98000 1 libsystem_kernel.dylib 0x0000000198af33a8 0x198adc000 + 95144 2 CoreFoundation 0x0000000198ef7bc4 0x198e4c000 + 703428 3 CoreFoundation 0x0000000198ef2a60 0x198e4c000 + 682592 4 CoreFoundation 0x0000000198ef21cc 0x198e4c000 + 680396 5 Foundation 0x00000001998e7404 0x1998df000 + 33796 6 Foundation 0x00000001998e72b0 0x1998df000 + 33456 7 UIKitCore 0x00000001c5e1a808 0x1c5445000 + 10311688 8 Foundation 0x0000000199a1a1ac 0x1998df000 + 1290668 9 libsystem_pthread.dylib 0x0000000198b832ac 0x198b78000 + 45740 10 libsystem_pthread.dylib 0x0000000198b8320c 0x198b78000 + 45580 11 libsystem_pthread.dylib 0x0000000198b86cf4 0x198b78000 + 60660 Thread 7: 0 libsystem_pthread.dylib 0x0000000198b86ce8 0x198b78000 + 60648 Thread 8: 0 libsystem_pthread.dylib 0x0000000198b86ce8 0x198b78000 + 60648 Thread 9: 0 libsystem_kernel.dylib 0x0000000198af3f24 0x198adc000 + 98084 1 libdispatch.dylib 0x0000000198943074 0x198941000 + 8308 2 libdispatch.dylib 0x00000001989439d0 0x198941000 + 10704 3 libdispatch.dylib 0x00000001989517ec 0x198941000 + 67564 4 libsystem_pthread.dylib 0x0000000198b832ac 0x198b78000 + 45740 5 libsystem_pthread.dylib 0x0000000198b8320c 0x198b78000 + 45580 6 libsystem_pthread.dylib 0x0000000198b86cf4 0x198b78000 + 60660 Thread 10 name: JavaScriptCore bmalloc scavenger Thread 10: 0 libsystem_kernel.dylib 0x0000000198afef0c 0x198adc000 + 143116 1 libsystem_pthread.dylib 0x0000000198b7bcd8 0x198b78000 + 15576 2 libc++.1.dylib 0x00000001980cc568 0x1980c4000 + 34152 3 JavaScriptCore 0x00000001a029ffd8 0x1a023e000 + 401368 4 JavaScriptCore 0x00000001a029fe88 0x1a023e000 + 401032 5 JavaScriptCore 0x00000001a029eb24 0x1a023e000 + 396068 6 JavaScriptCore 0x00000001a029e1e0 0x1a023e000 + 393696 7 JavaScriptCore 0x00000001a029fc8c 0x1a023e000 + 400524 8 libsystem_pthread.dylib 0x0000000198b832ac 0x198b78000 + 45740 9 libsystem_pthread.dylib 0x0000000198b8320c 0x198b78000 + 45580 10 libsystem_pthread.dylib 0x0000000198b86cf4 0x198b78000 + 60660 Thread 11 name: WTF::AutomaticThread Thread 11: 0 libsystem_kernel.dylib 0x0000000198afef0c 0x198adc000 + 143116 1 libsystem_pthread.dylib 0x0000000198b7bcd8 0x198b78000 + 15576 2 JavaScriptCore 0x00000001a0288b48 0x1a023e000 + 305992 3 JavaScriptCore 0x00000001a026fd10 0x1a023e000 + 204048 4 JavaScriptCore 0x00000001a0249654 0x1a023e000 + 46676 5 JavaScriptCore 0x00000001a02499f4 0x1a023e000 + 47604 6 JavaScriptCore 0x00000001a0286d60 0x1a023e000 + 298336 7 JavaScriptCore 0x00000001a02882c8 0x1a023e000 + 303816 8 libsystem_pthread.dylib 0x0000000198b832ac 0x198b78000 + 45740 9 libsystem_pthread.dylib 0x0000000198b8320c 0x198b78000 + 45580 10 libsystem_pthread.dylib 0x0000000198b86cf4 0x198b78000 + 60660 Thread 12 name: WTF::AutomaticThread Thread 12: 0 libsystem_kernel.dylib 0x0000000198afef0c 0x198adc000 + 143116 1 libsystem_pthread.dylib 0x0000000198b7bcd8 0x198b78000 + 15576 2 JavaScriptCore 0x00000001a0288b48 0x1a023e000 + 305992 3 JavaScriptCore 0x00000001a026fd10 0x1a023e000 + 204048 4 JavaScriptCore 0x00000001a0249654 0x1a023e000 + 46676 5 JavaScriptCore 0x00000001a02499f4 0x1a023e000 + 47604 6 JavaScriptCore 0x00000001a0286d60 0x1a023e000 + 298336 7 JavaScriptCore 0x00000001a02882c8 0x1a023e000 + 303816 8 libsystem_pthread.dylib 0x0000000198b832ac 0x198b78000 + 45740 9 libsystem_pthread.dylib 0x0000000198b8320c 0x198b78000 + 45580 10 libsystem_pthread.dylib 0x0000000198b86cf4 0x198b78000 + 60660 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000000000008 x1: 0x0000000000000001 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000281d30400 x5: 0x0000000000000080 x6: 0x00676f6c7379732f x7: 0x0000000000000ec0 x8: 0x0000000000000020 x9: 0x0000000281d30400 x10: 0xcccccccccccccccd x11: 0x000000000000000a x12: 0x0000000000000000 x13: 0x0000000000000031 x14: 0x0000000000000010 x15: 0x000000000000001c x16: 0x0000000000000209 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x0000000000000080 x20: 0x0000000281d30400 x21: 0x0000000000000000 x22: 0x0000000000000000 x23: 0x0000000000000001 x24: 0x0000000000000008 x25: 0x0000000000000001 x26: 0x0000000100eaec60 x27: 0x0000000000000000 x28: 0x0000000280f7c708 fp: 0x000000016f75e3f0 lr: 0x0000000198af7838 sp: 0x000000016f75e3b0 pc: 0x0000000198afddf8 cpsr: 0x40000000
We have a new build which assures compatibility with iOS 9 and 8 of the new timer implementation. You can get it here: https://www.dropbox.com/s/vqbrgqx04a68cnc/mobilesdk-7.4.2.v20181107185133-osx.zip?dl=0 [~venkateshkumarg], that crash is not symbolicated which does not really help us. Please provide a symbolicated crash log.
Hi Jan, Where i can get that symbolicated crash log. *Devices and OS* * iPhone (iOS12, iOS11, iOS10 and lesser version) - No crashes works perfectly * iPad (iOS11, iOS10 and lesser version) - No crashes works perfectly * iPad (iOS12) - *Crashing frequently for below scenario* *Scenario* * App launching without crashes and landing in dashboard page. * Now, Kill the app manually and Again, Open the app. * App crash issue occurred. Is below log will help to find the issue? 1 process_info [Scalepoint:335] SyscallError: setpriority(PRIO_DARWIN_ROLE, 335, 3): No such process 60 11:13:28.643549 +0530 assertiond 1 process_info SyscallError: task_info failed 60 11:13:28.648927 +0530 assertiond 1 process_info SyscallError: task_info failed 60 11:13:28.649062 +0530 assertiond 1 process_info SyscallError: task_info failed 60 11:13:28.651255 +0530 assertiond 1 process_info SyscallError: task_info failed 60 11:13:28.651454 +0530 assertiond 1 proc_state Can't get most elevated app state from dictionary { BKSApplicationStateExtensionKey = 0; SBApplicationStateDisplayIDKey = "com.scalepoint.ecbmobile"; SBApplicationStateKey = 0; SBApplicationStateProcessIDKey = 335; SBApplicationStateRunningReasonsKey = ( { SBApplicationStateRunningReasonAssertionIdentifierKey = "FBSceneSnapshotAction:com.scalepoint.ecbmobile"; SBApplicationStateRunningReasonAssertionReasonKey = 4; }, { SBApplicationStateRunningReasonAssertionIdentifierKey = Suspending; SBApplicationStateRunningReasonAssertionReasonKey = 10001; }, { SBApplicationStateRunningReasonAssertionIdentifierKey = "Shared Background Assertion 1 for com.scalepoint.ecbmobile"; SBApplicationStateRunningReasonAssertionReasonKey = 4; } ); } 105 11:13:28.742744 +0530 symptomsd 1 DataStore No data found at /var/mobile/Library/UserNotifications/com.scalepoint.ecbmobile/Topics.plist 50 11:13:29.236376 +0530 SpringBoard 1 Task <3AF38FBE-D39D-4E7A-A40E-0542AE71814C>.<1> finished with error - code: -1100 338 11:13:30.105377 +0530 Scalepoint 1 Task
[~venkateshkumarg], please see https://stackoverflow.com/questions/25855389/how-to-symbolicate-crash-log-xcode for information how to get symbolicated crash logs for your app from Xcode.
Hi Jan, Please check symbolicated crash logs of my app from Xcode in the below link https://www.dropbox.com/s/nhatk51tm0q4g0u/Scalepoint%20%2013-11-18%2C%204-14%20PM.txt?dl=0
[~venkateshkumarg], thank's for the symbolicated crash log. However, there are no indicators that this is related to JavaScriptCore or Timers. Please open a separate ticket and attach the crash log and, if possible, provide a reproducible test case, thanks.
Thanks Jan, Thanks for quick response. I will create new ticket with crash log and test case.
Hi All, We have received issue from one of our customer. The app is continuously crashing under IOS12. It is working under IOS11 without issues. As downgrade is not possible on IOS level they are frustrated and looking for a fix. We have already suggested to get recent Appcelerator SDK 7.4.2 and they have already added the possible jscore setting:
<use-jscore-framework>false</use-jscore-framework>For 7.4.2 and onward it is important to have jscore *enabled* to benefit from the fixes made in the ticket. Also, i'm unable to access the logs you shared (missing permissions).
Hi Jan, thanks for the update. I've shared the drive doc again. Please let me know if you can access this now.
[~aboldt], i see threads with
KrollTimerin your crash log which mean you are not running withuse-jscore-frameworkset to true andrun-on-main-threadalso set to true. Please make sure to properly configure the app intiapp.xmland enabled JSCore as well as run-on-main-thread, then test again with the most recent 7.4.2 build from my comment above.Hi Jan, Thanks for the quick feedback. Please confirm that the following within tiapp.xml is the correct setting
<property name="run-on-main-thread" type="bool">false</property> <ios> ... <use-jscore-framework>true</use-jscore-framework>See my previous comment,
run-on-main-threadmust betrue.Customer has tested changes but the crashes are still consistent. new crash logs have been uploaded to: https://drive.google.com/open?id=1FGrko2EKct1rv4ShqDiRJhD0AtM0Lc0Z. I have search for the mentioned KrollTimer in those new logs but they are not recorded anymore. any pointers what could be the reason on this? Thank you for your feedback.
Additional Log files can be found here: https://drive.google.com/open?id=1a-Qu3rd18-Ea0W2wyfvxTHMUOFdF76fz Can we please get this reviewed and let us know on how this can be resolved for the customer. Thanks for your help.
Your crash reports are not symbolicated. Please send the symbolicated crash reports to [mailto:jvennemann@axway.com] so we don't spam this ticket. Thanks!
Jan Vennemann, we are running our app based on: https://www.dropbox.com/s/vqbrgqx04a68cnc/mobilesdk-7.4.2.v20181107185133-osx.zip?dl=0 with the right flags on prod. Currently recording a bunch of the following crashes:
KrollContext.m Name SIGSEGV Reason SEGV_MAPERR Crashed Thread 0 JavaScriptCore 0x00000001bb8e027c JSC::LLInt::setUpCall() + 288 1 JavaScriptCore 0x00000001bb1cd120 llint_entry + 29948 2 JavaScriptCore 0x00000001bb1cd134 llint_entry + 29968 3 JavaScriptCore 0x00000001bb1cd134 llint_entry + 29968 4 JavaScriptCore 0x00000001bb1cd134 llint_entry + 29968 5 JavaScriptCore 0x00000001bb1cd134 llint_entry + 29968 6 JavaScriptCore 0x00000001bb1cd134 llint_entry + 29968 7 JavaScriptCore 0x00000001bb1cd598 llint_entry + 31092 8 JavaScriptCore 0x00000001bb1cd134 llint_entry + 29968 9 JavaScriptCore 0x00000001bb1cd0cc llint_entry + 29864 10 JavaScriptCore 0x00000001bb1c5a1c llintPCRangeStart + 296 11 JavaScriptCore 0x00000001bb83d3f0 JSC::Interpreter::executeCall() + 420 12 JavaScriptCore 0x00000001bb9f4068 JSC::profiledCall() + 168 13 JavaScriptCore 0x00000001bb1fb284 JSObjectCallAsFunction + 364 14 JavaScriptCore 0x00000001bb165284 -[JSValue callWithArguments:] + 288 ! 15 AppNameXXXX 0x000000010260595c -[KrollTimerTarget timerFired:] (KrollContext.m:1633) 16 Foundation 0x00000001b49785fc __NSFireTimer + 80 17 CoreFoundation 0x00000001b3e56bf0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 24 18 CoreFoundation 0x00000001b3e56920 __CFRunLoopDoTimer + 860 19 CoreFoundation 0x00000001b3e56154 __CFRunLoopDoTimers + 244 20 CoreFoundation 0x00000001b3e51030 __CFRunLoopRun + 1876 21 CoreFoundation 0x00000001b3e505b8 CFRunLoopRunSpecific + 432 22 GraphicsServices 0x00000001b60c4584 GSEventRunModal + 96 23 UIKitCore 0x00000001e0e48bc8 UIApplicationMain + 208 24 AppNameXXXX 0x00000001025f6e04 main (main.m:30) 25 libdyld.dylib 0x00000001b3910b94 start + 0I'm on TiSDK 7.5.0 GA and experiencing random crashes in regard to tableview layout and interaction on an iPhone running iOS 12.0.1. These iOS12 crashing problems need to be escalated and resolved as soon as possible. Should not be occurring on 7.5.0 GA. Essentially there is a survey with a scroll view consisting of about 15 table views with 7 rows per tableview. The app will crash when app is building the tableview row contents. Here is the start of crash log (i dont see option to add file here): I EMA 11-20-18, 11-50 AM.crash ncident Identifier: 692EA414-187F-4611-97B6-C0242C702DD8 CrashReporter Key: 784984f7c75d042e7cf638fab5227335f90e1750 Hardware Model: iPhone9,3 Process: EMA [734] Path: /private/var/containers/Bundle/Application/B43D450C-DBA9-4D2E-B92E-A512A6E93CE2/EMA.app/EMA Identifier: com.pilrhealth.ema Version: 1.2.0 (1.2.0) Code Type: ARM-64 (Native) Role: Non UI Parent Process: launchd [1] Coalition: com.pilrhealth.ema [654] Date/Time: 2018-11-20 11:50:07.9619 -0800 Launch Time: 2018-11-20 11:43:59.7720 -0800 OS Version: iPhone OS 12.0.1 (16A404) Baseband Version: 3.00.01 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000040 VM Region Info: 0x40 is not in any region. Bytes before following region: 4306468800 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 0000000100af8000-0000000100e3c000 [ 3344K] r-x/r-x SM=COW ...2/EMA.app/EMA Triggered by Thread: 4 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0: 0 libsystem_kernel.dylib 0x00000001cc951ed0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x00000001cc9513a8 mach_msg + 72 2 CoreFoundation 0x00000001ccd55fb0 __CFRunLoopServiceMachPort + 236 3 CoreFoundation 0x00000001ccd50e4c __CFRunLoopRun + 1396 4 CoreFoundation 0x00000001ccd505b8 CFRunLoopRunSpecific + 436 5 GraphicsServices 0x00000001cefc4584 GSEventRunModal + 100 6 UIKitCore 0x00000001f9d14bc8 UIApplicationMain + 212 7 EMA 0x0000000100afff10 main + 32528 (main.m:29) 8 libdyld.dylib 0x00000001cc810b94 start + 4 Thread 1: 0 libsystem_pthread.dylib 0x00000001cc9e4cfc start_wqthread + 0 Thread 2: 0 libsystem_pthread.dylib 0x00000001cc9e4cfc start_wqthread + 0 Thread 3 name: com.apple.uikit.eventfetch-thread Thread 3: 0 libsystem_kernel.dylib 0x00000001cc951ed0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x00000001cc9513a8 mach_msg + 72 2 CoreFoundation 0x00000001ccd55fb0 __CFRunLoopServiceMachPort + 236 3 CoreFoundation 0x00000001ccd50e4c __CFRunLoopRun + 1396 4 CoreFoundation 0x00000001ccd505b8 CFRunLoopRunSpecific + 436 5 Foundation 0x00000001cd7446a4 -[NSRunLoop+ 34468 (NSRunLoop) runMode:beforeDate:] + 300 6 Foundation 0x00000001cd744550 -[NSRunLoop+ 34128 (NSRunLoop) runUntilDate:] + 148 7 UIKitCore 0x00000001f9e0141c -[UIEventFetcher threadMain] + 136 8 Foundation 0x00000001cd8773b0 _NSThreadstart_ + 1040 9 libsystem_pthread.dylib 0x00000001cc9e12fc _pthread_body + 128 10 libsystem_pthread.dylib 0x00000001cc9e125c _pthread_start + 48 11 libsystem_pthread.dylib 0x00000001cc9e4d08 thread_start + 4 Thread 4 name: KrollContext
[~jonkravetz], your app is not running on main thread. Please add
<property name="run-on-main-thread" type="bool">true</property>to your tiapp.xml. If the issue persists open a new ticket and submit a reproducible test case.I changed the "run-on-main-thread" property to true and the issue still persists: It is hard for me to figure out how I can submit a reproducible test case in this situation, because the app has a robust architecture and it would be difficult/time-consuming to figure out how separate this functionality for sharing. Here is the crash log:
Incident Identifier: E5EE2A38-6D87-485C-A309-33F3D2C028BD CrashReporter Key: 784984f7c75d042e7cf638fab5227335f90e1750 Hardware Model: iPhone9,3 Process: EMA [1120] Path: /private/var/containers/Bundle/Application/6FB5B8A3-7F47-4B8E-8FD0-564897D3CE9E/EMA.app/EMA Identifier: com.pilrhealth.ema Version: 1.2.0 (1.2.0) Code Type: ARM-64 (Native) Role: Non UI Parent Process: launchd [1] Coalition: com.pilrhealth.ema [1036] Date/Time: 2018-11-21 06:50:54.4200 -0800 Launch Time: 2018-11-21 06:45:38.7734 -0800 OS Version: iPhone OS 12.0.1 (16A404) Baseband Version: 3.00.01 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000040 VM Region Info: 0x40 is not in any region. Bytes before following region: 4304273344 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 00000001008e0000-0000000100c24000 [ 3344K] r-x/r-x SM=COW ...E/EMA.app/EMA Triggered by Thread: 4 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0: 0 libsystem_kernel.dylib 0x00000001cc951ed0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x00000001cc9513a8 mach_msg + 72 2 CoreFoundation 0x00000001ccd55fb0 __CFRunLoopServiceMachPort + 236 3 CoreFoundation 0x00000001ccd50e4c __CFRunLoopRun + 1396 4 CoreFoundation 0x00000001ccd505b8 CFRunLoopRunSpecific + 436 5 GraphicsServices 0x00000001cefc4584 GSEventRunModal + 100 6 UIKitCore 0x00000001f9d14bc8 UIApplicationMain + 212 7 EMA 0x00000001008e7f10 main + 32528 (main.m:29) 8 libdyld.dylib 0x00000001cc810b94 start + 4 Thread 1: 0 libsystem_pthread.dylib 0x00000001cc9e4cfc start_wqthread + 0 Thread 2: 0 libsystem_pthread.dylib 0x00000001cc9e4cfc start_wqthread + 0 Thread 3 name: com.apple.uikit.eventfetch-thread Thread 3: 0 libsystem_kernel.dylib 0x00000001cc951ed0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x00000001cc9513a8 mach_msg + 72 2 CoreFoundation 0x00000001ccd55fb0 __CFRunLoopServiceMachPort + 236 3 CoreFoundation 0x00000001ccd50e4c __CFRunLoopRun + 1396 4 CoreFoundation 0x00000001ccd505b8 CFRunLoopRunSpecific + 436 5 Foundation 0x00000001cd7446a4 -[NSRunLoop+ 34468 (NSRunLoop) runMode:beforeDate:] + 300 6 Foundation 0x00000001cd744550 -[NSRunLoop+ 34128 (NSRunLoop) runUntilDate:] + 148 7 UIKitCore 0x00000001f9e0141c -[UIEventFetcher threadMain] + 136 8 Foundation 0x00000001cd8773b0 __NSThread__start__ + 1040 9 libsystem_pthread.dylib 0x00000001cc9e12fc _pthread_body + 128 10 libsystem_pthread.dylib 0x00000001cc9e125c _pthread_start + 48 11 libsystem_pthread.dylib 0x00000001cc9e4d08 thread_start + 4 Thread 4 name: KrollContext<kroll$1> Thread 4 Crashed: 0 JavaScriptCore 0x00000001d47e0280 JSC::LLInt::setUpCall+ 7848576 (JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 296 1 JavaScriptCore 0x00000001d47e01a4 JSC::LLInt::setUpCall+ 7848356 (JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 76 2 JavaScriptCore 0x00000001d40cd120 llint_entry + 29952 3 JavaScriptCore 0x00000001d40cd4e0 llint_entry + 30912 4 JavaScriptCore 0x00000001d40cd0cc llint_entry + 29868 5 JavaScriptCore 0x00000001d40cd0cc llint_entry + 29868 6 JavaScriptCore 0x00000001d40cd0cc llint_entry + 29868 7 JavaScriptCore 0x00000001d40cd0cc llint_entry + 29868 8 JavaScriptCore 0x00000001d40cd134 llint_entry + 29972 9 JavaScriptCore 0x00000001d40cd134 llint_entry + 29972 10 JavaScriptCore 0x00000001d40c5a1c vmEntryToJavaScript + 300 11 JavaScriptCore 0x00000001d473d3f0 JSC::Interpreter::executeCall+ 7181296 (JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 424 12 JavaScriptCore 0x00000001d48f4068 JSC::profiledCall+ 8978536 (JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 172 13 JavaScriptCore 0x00000001d40fb284 JSObjectCallAsFunction + 368 14 EMA 0x00000001008fb1e0 -[KrollCallback call:thisObject:] + 111072 (KrollCallback.m:149) 15 EMA 0x00000001008fc914 -[KrollEvent invoke:] + 117012 (KrollContext.m:732) 16 EMA 0x00000001008fdc64 -[KrollContext invoke:] + 121956 (KrollContext.m:1002) 17 EMA 0x00000001008ff290 -[KrollContext main] + 127632 (KrollContext.m:1374) 18 Foundation 0x00000001cd8773b0 __NSThread__start__ + 1040 19 libsystem_pthread.dylib 0x00000001cc9e12fc _pthread_body + 128 20 libsystem_pthread.dylib 0x00000001cc9e125c _pthread_start + 48 21 libsystem_pthread.dylib 0x00000001cc9e4d08 thread_start + 4 Thread 5 name: JavaScriptCore bmalloc scavenger Thread 5: 0 libsystem_kernel.dylib 0x00000001cc95cf0c __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x00000001cc9d9d48 _pthread_cond_wait$VARIANT$mp + 636 2 libc++.1.dylib 0x00000001cbf28568 std::__1::condition_variable::__do_timed_wait+ 34152 (std::__1::unique_lock<std::__1::mutex>&, std::__1::chrono::time_point<std::__1::chrono::system_clock, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> > >) + 96 3 JavaScriptCore 0x00000001d40c539c std::__1::cv_status std::__1::condition_variable::wait_until<std::__1::chrono::steady_clock, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> > >+ 398236 (std::__1::unique_lock<std::__1::mutex>&, std::__1::chrono::time_point<std::__1::chrono::steady_clock, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> > > const&) + 124 4 JavaScriptCore 0x00000001d40c524c std::__1::cv_status std::__1::condition_variable_any::wait_until<std::__1::unique_lock<bmalloc::Mutex>, std::__1::chrono::steady_clock, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> > >+ 397900 (std::__1::unique_lock<bmalloc::Mutex>&, std::__1::chrono::time_point<std::__1::chrono::steady_clock, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> > > const&) + 112 5 JavaScriptCore 0x00000001d40c3ee8 bmalloc::Scavenger::threadRunLoop+ 392936 () + 296 6 JavaScriptCore 0x00000001d40c35a4 bmalloc::Scavenger::Scavenger+ 390564 (std::__1::lock_guard<bmalloc::Mutex>&) + 0 7 JavaScriptCore 0x00000001d40c5050 std::__1::__thread_specific_ptr<std::__1::__thread_struct>::set_pointer+ 397392 (std::__1::__thread_struct*) + 0 8 libsystem_pthread.dylib 0x00000001cc9e12fc _pthread_body + 128 9 libsystem_pthread.dylib 0x00000001cc9e125c _pthread_start + 48 10 libsystem_pthread.dylib 0x00000001cc9e4d08 thread_start + 4 Thread 6 name: WTF::AutomaticThread Thread 6: 0 libsystem_kernel.dylib 0x00000001cc95cf0c __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x00000001cc9d9d48 _pthread_cond_wait$VARIANT$mp + 636 2 JavaScriptCore 0x00000001d40adf34 WTF::ThreadCondition::timedWait+ 302900 (WTF::Mutex&, WTF::WallTime) + 148 3 JavaScriptCore 0x00000001d40950f4 WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void + 200948 ()> const&, WTF::TimeWithDynamicClockType const&) + 2004 4 JavaScriptCore 0x00000001d406ea38 bool WTF::Condition::waitUntil<WTF::Lock>+ 43576 (WTF::Lock&, WTF::TimeWithDynamicClockType const&) + 184 5 JavaScriptCore 0x00000001d406edd8 WTF::Function<void ()>::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0>::call+ 44504 () + 216 6 JavaScriptCore 0x00000001d40ac14c WTF::Thread::entryPoint+ 295244 (WTF::Thread::NewThreadContext*) + 256 7 JavaScriptCore 0x00000001d40ad6b4 WTF::wtfThreadEntryPoint+ 300724 (void*) + 12 8 libsystem_pthread.dylib 0x00000001cc9e12fc _pthread_body + 128 9 libsystem_pthread.dylib 0x00000001cc9e125c _pthread_start + 48 10 libsystem_pthread.dylib 0x00000001cc9e4d08 thread_start + 4 Thread 7 name: com.apple.NSURLConnectionLoader Thread 7: 0 libsystem_kernel.dylib 0x00000001cc951ed0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x00000001cc9513a8 mach_msg + 72 2 CoreFoundation 0x00000001ccd55fb0 __CFRunLoopServiceMachPort + 236 3 CoreFoundation 0x00000001ccd50e4c __CFRunLoopRun + 1396 4 CoreFoundation 0x00000001ccd505b8 CFRunLoopRunSpecific + 436 5 CFNetwork 0x00000001cd370e18 -[__CoreSchedulingSetRunnable runForever] + 212 6 Foundation 0x00000001cd8773b0 __NSThread__start__ + 1040 7 libsystem_pthread.dylib 0x00000001cc9e12fc _pthread_body + 128 8 libsystem_pthread.dylib 0x00000001cc9e125c _pthread_start + 48 9 libsystem_pthread.dylib 0x00000001cc9e4d08 thread_start + 4 Thread 8 name: JSC Heap Collector Thread Thread 8: 0 libsystem_kernel.dylib 0x00000001cc95cf0c __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x00000001cc9d9d48 _pthread_cond_wait$VARIANT$mp + 636 2 JavaScriptCore 0x00000001d40adf34 WTF::ThreadCondition::timedWait+ 302900 (WTF::Mutex&, WTF::WallTime) + 148 3 JavaScriptCore 0x00000001d40950f4 WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void + 200948 ()> const&, WTF::TimeWithDynamicClockType const&) + 2004 4 JavaScriptCore 0x00000001d406ea38 bool WTF::Condition::waitUntil<WTF::Lock>+ 43576 (WTF::Lock&, WTF::TimeWithDynamicClockType const&) + 184 5 JavaScriptCore 0x00000001d406edd8 WTF::Function<void ()>::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0>::call+ 44504 () + 216 6 JavaScriptCore 0x00000001d40ac14c WTF::Thread::entryPoint+ 295244 (WTF::Thread::NewThreadContext*) + 256 7 JavaScriptCore 0x00000001d40ad6b4 WTF::wtfThreadEntryPoint+ 300724 (void*) + 12 8 libsystem_pthread.dylib 0x00000001cc9e12fc _pthread_body + 128 9 libsystem_pthread.dylib 0x00000001cc9e125c _pthread_start + 48 10 libsystem_pthread.dylib 0x00000001cc9e4d08 thread_start + 4 Thread 9: 0 libsystem_pthread.dylib 0x00000001cc9e4cfc start_wqthread + 0 Thread 10: 0 libsystem_pthread.dylib 0x00000001cc9e4cfc start_wqthread + 0 Thread 11: 0 libsystem_pthread.dylib 0x00000001cc9e4cfc start_wqthread + 0 Thread 12: 0 libsystem_pthread.dylib 0x00000001cc9e4cfc start_wqthread + 0 Thread 4 crashed with ARM Thread State (64-bit): x0: 0x00000001035ad880 x1: 0x00000001035ad880 x2: 0x0000000000000000 x3: 0x0000000105f805a0 x4: 0x0000000104bc6090 x5: 0x0000000000000066 x6: 0x000000016f861af0 x7: 0x0000000000000000 x8: 0x0000000000000000 x9: 0x0000000102e42000 x10: 0x000000000000001f x11: 0x0000000000000008 x12: 0x00000000004a32e5 x13: 0x0000000040000000 x14: 0x0000000000000000 x15: 0x0000000000073e80 x16: 0x0000000000074010 x17: 0x00000001d40cd024 x18: 0x0000000000000000 x19: 0x000000016f862000 x20: 0x000000016f8620f0 x21: 0x0000000105f805a0 x22: 0x0000000102e00000 x23: 0x0000000102e00000 x24: 0x0000000107f79a10 x25: 0x0000000102d30048 x26: 0x0000000000000000 x27: 0xffff000000000000 x28: 0xffff000000000002 fp: 0x000000016f861fa0 lr: 0x00000001d47e01a4 sp: 0x000000016f861f30 pc: 0x00000001d47e0280 cpsr: 0x80000000Crashes with 7.5.0.GA in Production:
Name SIGSEGV Reason SEGV_MAPERR App Version Download Crashed Thread 0 JavaScriptCore 0x00000001f1550820 JSC::ASTBuilder::makeAssignNode() + 68 1 libdyld.dylib 0x00000001e93e5050 dyld3::ScopedTimer::startTimer() + 20KrollContext.m Name SIGSEGV Reason SEGV_MAPERR App Version 6.0.9 (6.0.9) Download Crashed Thread 0 JavaScriptCore 0x00000001bf616c0c JSC::LLInt::setUpCall() + 292 1 JavaScriptCore 0x00000001bef03d78 llint_entry + 29988 2 JavaScriptCore 0x00000001bef04138 llint_entry + 30948 3 JavaScriptCore 0x00000001bef03d8c llint_entry + 30008 4 JavaScriptCore 0x00000001bef04138 llint_entry + 30948 5 JavaScriptCore 0x00000001bef03d8c llint_entry + 30008 6 JavaScriptCore 0x00000001bef03d8c llint_entry + 30008 7 JavaScriptCore 0x00000001bef04138 llint_entry + 30948 8 JavaScriptCore 0x00000001bef03d8c llint_entry + 30008 9 JavaScriptCore 0x00000001bef03d8c llint_entry + 30008 10 JavaScriptCore 0x00000001beefc654 llintPCRangeStart + 304 11 JavaScriptCore 0x00000001bf572c64 JSC::Interpreter::executeProgram() + 9616 12 JavaScriptCore 0x00000001bf74dbdc JSC::evaluate() + 316 13 JavaScriptCore 0x00000001bef252b4 JSEvaluateScript + 484 ! 14 XXXXXX 0x0000000104aa7fa0 -[KrollEval jsInvokeInContext:exception:] (KrollContext.m:647) 15 XXXXXX 0x0000000104aa525c -[KrollBridge loadCommonJSModule:withSourceURL:] (KrollBridge.m:749) 16 XXXXXX 0x0000000104aa5ce0 -[KrollBridge loadJavascriptText:fromFile:withContext:] (KrollBridge.m:935) 17 XXXXXX 0x0000000104aa5f3c -[KrollBridge loadAsFile:withContext:] (KrollBridge.m:999) 18 XXXXXX 0x0000000104aa6150 -[KrollBridge loadAsFileOrDirectory:withContext:] (KrollBridge.m:1068) 19 XXXXXX 0x0000000104aa6668 -[KrollBridge require:path:] (KrollBridge.m:1174) 20 XXXXXX 0x0000000104aa91a0 CommonJSRequireCallback (KrollContext.m:253) 21 JavaScriptCore 0x00000001bef25d30 JSC::APICallbackFunction::call<JSC::JSCallbackFunction>() + 344 22 JavaScriptCore 0x00000001bef04930 llint_entry + 32988 23 JavaScriptCore 0x00000001bef03d8c llint_entry + 30008 24 JavaScriptCore 0x00000001bef03d8c llint_entry + 30008 25 JavaScriptCore 0x00000001bef03d8c llint_entry + 30008 26 JavaScriptCore 0x00000001beefc654 llintPCRangeStart + 304 27 JavaScriptCore 0x00000001bf572c64 JSC::Interpreter::executeProgram() + 9616 28 JavaScriptCore 0x00000001bf74dbdc JSC::evaluate() + 316 29 JavaScriptCore 0x00000001bef252b4 JSEvaluateScript + 484 30 XXXXXX 0x0000000104aa4140 -[KrollBridge evalFileOnThread:context:] (KrollBridge.m:425) 31 XXXXXX 0x0000000104aa7bd8 -[KrollInvocation invoke:] (KrollContext.m:105) 32 XXXXXX 0x0000000104aa8860 -[KrollContext invoke:] (KrollContext.m:1002) 33 XXXXXX 0x0000000104aa4bd0 -[KrollBridge didStartNewContext:] (KrollBridge.m:0) 34 XXXXXX 0x0000000104aa9108 -[KrollContext main] (KrollContext.m:1281) 35 libdispatch.dylib 0x00000001b75fd6c8 _dispatch_call_block_and_release + 20 36 libdispatch.dylib 0x00000001b75fe484 _dispatch_client_callout + 12 37 libdispatch.dylib 0x00000001b75ddb44 _dispatch_main_queue_callback_4CF$VARIANT$armv81 + 1008 38 CoreFoundation 0x00000001b7b53dd0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8 39 CoreFoundation 0x00000001b7b4ec98 __CFRunLoopRun + 1960 40 CoreFoundation 0x00000001b7b4e1cc CFRunLoopRunSpecific + 432 41 GraphicsServices 0x00000001b9dc5584 GSEventRunModal + 96 42 UIKitCore 0x00000001e4dc5054 UIApplicationMain + 208 43 XXXXXX 0x0000000104a9bdd8 main (main.m:29) 44 libdyld.dylib 0x00000001b760ebb4 start + 0main.m Name SIGSEGV Reason SEGV_MAPERR App Version 6.0.9 (6.0.9) Download Crashed Thread 0 JavaScriptCore 0x00000001d1d96c0c JSC::LLInt::setUpCall() + 292 1 JavaScriptCore 0x00000001d1683d78 llint_entry + 29988 2 JavaScriptCore 0x00000001d1683d24 llint_entry + 29904 3 JavaScriptCore 0x00000001d1683d24 llint_entry + 29904 4 JavaScriptCore 0x00000001d1683d8c llint_entry + 30008 5 JavaScriptCore 0x00000001d1683d24 llint_entry + 29904 6 JavaScriptCore 0x00000001d1683d8c llint_entry + 30008 7 JavaScriptCore 0x00000001d1683d8c llint_entry + 30008 8 JavaScriptCore 0x00000001d1683d8c llint_entry + 30008 9 JavaScriptCore 0x00000001d16841f0 llint_entry + 31132 10 JavaScriptCore 0x00000001d1683d8c llint_entry + 30008 11 JavaScriptCore 0x00000001d1683d24 llint_entry + 29904 12 JavaScriptCore 0x00000001d167c654 llintPCRangeStart + 304 13 JavaScriptCore 0x00000001d1cf4070 JSC::Interpreter::executeCall() + 420 14 JavaScriptCore 0x00000001d1eaaa2c JSC::profiledCall() + 184 15 JavaScriptCore 0x00000001d16b202c JSObjectCallAsFunction + 364 16 JavaScriptCore 0x00000001d161be94 -[JSValue callWithArguments:] + 288 17 Foundation 0x00000001cadf73f8 __NSFireTimer + 80 18 CoreFoundation 0x00000001ca2d4804 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 24 19 CoreFoundation 0x00000001ca2d4534 __CFRunLoopDoTimer + 860 20 CoreFoundation 0x00000001ca2d3d68 __CFRunLoopDoTimers + 244 21 CoreFoundation 0x00000001ca2cec44 __CFRunLoopRun + 1876 22 CoreFoundation 0x00000001ca2ce1cc CFRunLoopRunSpecific + 432 23 GraphicsServices 0x00000001cc545584 GSEventRunModal + 96 24 UIKitCore 0x00000001f7545054 UIApplicationMain + 208 ! 25 XXXXXX 0x0000000100733dd8 main (main.m:29) 26 libdyld.dylib 0x00000001c9d8ebb4 start + 0[~jonkravetz], if the issue persists, please update your crash report. If you can't provide an isolated test case consider providing us your app project for better insight if that is possible. As already mentioned multiple times in this ticket, you can send them privately to [mailto:jvennemann@axway.com] or [mailto:vsingh@axway.com].
Hi Jan, I just sent you an email with github branch access and steps to reproduce. Please let us know what you think is going on and/or followup with any additional questions. We are still experiencing the intermittent crashing. Thanks, Jon Kravetz
7.5.0 Is causing random crashes again. 7.4.2 was fine on our project
I have the same problem of Leonardo Amigoni 7.5.0 Is causing random crashes again
Thanks for the feedback guys, especially [~jonkravetz] for providing his project as a test case. We are looking into it and let you know once we have an update.
I have started using new titanium 7.5.0 and got app crush and it gave me following error on console, Its working fine with 7.4.2 though I have set following properties to false in my tiapp.xml as it was working fine only with false in 7.4.0
[~ppancholi] you will need to put the properties on true for the fix to be applied. Can you try it with that?
Please note that the use-jscore-framework is no property and rather has to go inside the
<ios>section as a node if you specifiy it. Using JSCore is true by default. The structure of youtiapp.xmlshould look like this.<ti:app> <property name="run-on-main-thread" type="bool">true</property> <ios> <use-jscore-framework>true</use-jscore-framework> <!-- optional, true by default since 7.0.0 --> </ios> </ti:app>Thanks for help! It's working fine with properties set to true
Wondering whether there are any updates for this issue? We provided our code and are interested to know whether it has been tested, if there is any feedback.
This is very confusing. I have been following this thread for a while on and off now. Earlier on people were saying you need to set the "use-jscore-framework" flag to false to get things to work. Now @jvennemann is saying use true. What exactly does this flag do and how does it affect performance? Again from earlier reading of comments it seemed that all this flag does is allow debugging in Safari (which is not needed usually), but maybe it has more reach than that. In our app we moved from Ti SDK 7.4.1 to 7.5.0 and had an immediate improvement in performance (everything faster with no freezes). But we are using "use-jscore-framework" set to false.
[~jonkravetz], we have received another test case which lets us reproduce the issue in 7.5.0 reliably and we have found the change in 7.5.0 that introduced the issue. Working on a fix right now! [~icecandyent], use-jscore-framework switches from our legacy TiCore to the official JavaScriptCore framework from Apple as the JavaScript runtime. TiCore is an old fork of JavaScriptCore which we did to implement various changes that were necessary in the earlier days of Titanium. Since then Apple's official JavaScriptCore framework also implemented those changes and we could switch back to use that and also benefit from all the optimizations and improvements Apple implemented there. In 8.0.0, TiCore will be removed and JavaScriptCore is the only available JS runtime on iOS. So it does a little more than just "allowing debugging in Safari". When this issue first came up it was an easy workaround to use TiCore because the issue was related to GC optimizations done by Apple in JavaScriptCore. For others the changing the
ron-on-main-threadproperty also seemed to help. If this property is set to false, JavaScript execution runs on a separate thread. Since this can cause issues when interacting with the UI (which always needs to be done on the main thread) this property is also deprecated and will be removed in 8.0.0. After making several fixes to our core users could switch back to use JavaScriptCore andrun-on-main-thread. We have a few outstanding reports about continued crashes which we are investigating. Hope this clears up a few things![~jvennemann] thank you very much for the clear explanation. I hope you are putting this somewhere important in the Ti docs!
we're waiting for the fix too, hope this is coming out soon!
[~jvennemann] is there already an idea if this is going to be fixed in 7.5.1? I don't see anything related in the current milestone on Github yet.
Alright guys, here is the latest 7.5.1 build addressing the reoccurring crashes some of you were seeing with 7.5.0.GA. https://www.dropbox.com/s/dwgcxtk5fmwfl41/mobilesdk-7.5.1.v20181211045525-osx.zip?dl=0 Please give it a try and let us now how this version works for you. We were seeing positive results in our test case and no more crashes occurred even after several iterations.
[~jvandijk], the corresponding PR is https://github.com/appcelerator/titanium_mobile/pull/10525 and it was solved together with TIMOB-26452
[~jvennemann] Looking good so far. Running your test build for 2 days now and haven't seen a freeze myself yet.
Just saw the blog post addressing this issue. I'd like to thank the whole team that worked hard to make it work, especially @Jan Vennemann for his comments and explanations! I'm just a little bit confused on what's the best release to use and settings. I understand that we should use _run-on-main-thread_ and _use-jscore-framework_ set to *true* but with the blog post about the 7.4.2.GA release and 7.5.1 I'm not sure which one is the recommended version. Please correct me if I'm mistaken, but 7.4.2 addresses bugs and issues and this one is included, but 7.5.1 has a lot of improvements, new features and fixes + this one, is that correct? Gonna give them a try and let you know! Thanks again
[~chmiiller], basically you are correct. Except that 7.4.2.GA contains the fixes made for this ticket only, nothing else. 7.5.1.GA also has the fixes made for this ticket along wither other high priority fixes for 7.5.0.GA. And since 7.5.X was a minor update it contains a lot of other new features and fixes compared to the 7.4.X branch as well.
I had hoped that everything was fixed, but maybe I found an error connected to this ticket. When I pause my app with a setInterval running, and then resume it, I get this error (shown as many times as the interval run in the background) !https://cdn1.imggmi.com/uploads/2019/1/30/cb2b0b94c4933b97d2c640a18201553f-full.png!
[~a.marcone], could you please open a separate ticket and post a simple test case? Usually timers will be suspended when the app switches to background and resume once it enters foreground again so they shouldn't fire when app is paused.
sorry, I replied to this ticket only because this is happening only after updating to the above mentioned sdk and I never experienced anything like that - especially because the error mentions the JSContext and timer that were the culprit of the issues from other users.
[~rmitro], you can use TIMOB-26852 for follow up issues related to JSCore crashes. Please attach the crash log to that ticket and include as much additional info as you can provide. Test cases or full example projects are always a big help for such crashes since they are hard to pin down with just the crash log. Thanks!