[TIMOB-23435] Hyperloop: iOS Memory Leak
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Critical |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2016-07-27T18:55:30.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 5.4.0 |
| Components | Hyperloop, iOS |
| Labels | n/a |
| Reporter | Andrew McElroy |
| Assignee | Eric Merriman |
| Created | 2016-05-19T18:56:56.000+0000 |
| Updated | 2017-03-31T22:16:38.000+0000 |
Description
Attachments
| File | Date | Size |
|---|---|---|
| Screen Shot 2016-07-18 at 11.09.09 AM.png | 2016-07-18T18:23:36.000+0000 | 822455 |
[~sophrinix] Are you "only" having the issues with the Autolayout-API or even without it? It would be good to have an actual video to see how it increases. I will try to setup something similar.
Any iOS HL example leaks memory. Any time you require HL objects, you are leaking, I think. Just run the Instruments Leak tool on the iOS sim build to see what I am talking about. I did a video of this back in Feb. https://www.dropbox.com/s/i0yxar3dxrly2yu/kroll-context-memory-leak-with-hyperloop.mp4?dl=0
[~hansknoechel] This may sound crazy but. I used the latest 1.2.3 Hyperloop module on github, and I don't see a single leak. Neither on a new app, nor on the hyperloop-example. environment: hyperloop: 1.2.3 Ti SDK : 5.4.0.v20160519143319 Xcode 7.3.1
It is still leaking. I cloned down a copy of hyperloop-examples and grabbed that exact 1.2.3 version of hyperloop module from releases. I'll upload a video and a new trace in the next hour or so.
[~cng], Will do.
[~cng] I am able to reproduce this issue, It happens upon opening most of the items in the sample application.
ENV
iOS Simulator (9.3) Mac OSX El Capitan 10.11.5 Studio: 4.7.0.201607130543 Ti SDK: 5.4.0.v20160713141635 Hyperloop: 1.2.3 (Pulled from master and built today) Appc NPM: 4.2.7 Appc CLI: 5.4.0-31 Node v4.4.4Leaked objects from auto layout (Complete list [Here](https://gist.github.com/longton95/b764a42e442821ce0bb3b14b58790b09))
Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f81924994b0 64 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da6b30 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,15 < multiple > 784 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8192461db0 32 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f81924994f0 48 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193da8330 32 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193da8550 48 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193da8710 32 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193da91e0 96 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193da9310 32 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193da93f0 48 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193da9a30 32 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193da9e50 96 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193da9f40 32 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193daa0d0 96 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193daa180 96 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193daa2f0 32 Hyperloop_Sample NSStringFromTiStringRef __NSCFString,1 0x7f8193daa360 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8192461db0 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f81924994f0 48 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da8330 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da8550 48 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da8710 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da91e0 96 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da9310 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da93f0 48 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da9a30 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da9e50 96 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da9f40 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193daa0d0 96 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193daa180 96 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193daa2f0 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193daa360 32 Hyperloop_Sample NSStringFromTiStringRef Leaked Object,# Address Size Responsible Library Responsible Frame KrollObject,1 0x7f81926056c0 80 Hyperloop_Sample -[KrollContext main] Leaked Object,# Address Size Responsible Library Responsible Frame __NSCFString,1 0x7f8193da9170 48 Hyperloop_Sample NSStringFromTiStringRefUsing another build, I was able to run the example application without getting any leaks. We will continue to investigate to see what is happening.
Explanation for KrollObject seemingly 'growing' leak
If you observe the video in ticket, you will see the spread graph of KrollObject continuously growing branches, that can look pretty scary. But further investigation proved that it doesn't imply continuous allocation of memory.Steps to reproduce
1. You can use the hyperloop-examples, but siong the simple sample code i have in earlier comments can reproduce as well. 2. Configure leaks to take snapshots every 5s 3. Use instruments on device as discussed in earlier comment. 4. Every 5s you will notice branches growing on KrollObject 5. But if you choose allocation, and click 'mark generation'. First time it'll show you the amount of memory allocated since the start of the application. 6. Subsequent clicking of 'mark generation' will show the delta in memory allocation. You will see that it's always '0' implying there's no memory allocation. *Note*: Without using hyperloop, on Titanium this will also show as a Root Leak. but same thing applies.About *use-jscore-framework*
As recommended on our hyperloop guide, we should set this property to true when using hyperloop. However, currently this doesn't support our debugger implementation but we'll be working on it very soon! If we really want to use debugger on studio, we can set this property to false. Nothing will change functionally, but you will notice that if this is set to false, new leaks will appear on instruments. However, we have verified that these leaks are false negatives. To make sure it's really not leaking: - InCycles & Roots > Leak Cycles, click the right arrow when hovering the mouse-pointer over the leak, and look at the final retain count. it's actually zero, so it's not a leak. - If it's not zero, look for 2 consecutive callers namedInitializer. In this method, we actually explicitly retain memory, that will be released during garbage collection. So instrument doesn't know it'll be released during garbage collection because we are actually using our legacy Titanium Core (variant of JavascriptCore) that its not familiar with. (Which explains why whenuse-jscore-frameworkis set to true, you won't see any leaks at all because it knows how garbage collection works in their own javascriptcore framework}}. So we can safely assume that as long as there's no leaks whenuse-jscore-frameworkis true, hyperloop module is good. If you do still see leaks, make sure that you have implemented the iOS API correctly (see above URLSession leak), it may not be related to the hyperloop module at all. All in all, PR is ready to be reviewed and merged. https://github.com/appcelerator/hyperloop.next/pull/41 Here is a PR for hyperloop-examples as well. https://github.com/appcelerator/hyperloop-examples/pull/37 If you are experiencing crashes when using hyperloop, please file tickets with as much descriptions as possible![~sophrinix] Can you do a functional test first?
PR approved. [~cng] Please draft a new release on Github, since you should decide if we do the bump or not. Thanks!
1.2.5 is substantially better than previous versions. however there are still leaks. Here is a dropbox url of a tracefile I ran during the hyperloop standup. https://www.dropbox.com/sh/wozuk5j7scdbcfm/AABKXaTIWiryY8AkXsvdsrp6a?dl=0
[~sophrinix] looking at the trace, (ignoring Kroll as explained above), it seems to be only on NSURL related code. Are you using the latest hyperloop-example? see my comment wrt above: - leaks appearing from "HTTP Request" and only here -- This is primarily because our example code did not have session.finishTasksAndInvalidate(), required even in ARC to release memory. -- http://stackoverflow.com/questions/21554987/nsurlsession-memory-leaks-occur-when-using-web-services-in-ios I have already merged a PR that addresses this URLRequest leak.
Closing ticket as fixed, if there are any problems, please file a new ticket.