I'm developing Keyboard Extension on iOS 8.3
While developing there is a memory leak somewhere after calling advanceToNextInputMode.
And the Responsible Frame and leaked Object are looks like totally out of my control.
Can anybody meet anything similar problem?
I have this exact problem. It is Apple's fault. The total amount of memory leaked is pretty tiny though. File a bug report so they'll take it more seriously (I've already filed, but more always help).
Related
I have an IOS app that displays images and text in a UITableView. When I scroll up and down I get this unbounded memory growth. I have used Allocations to attempt to find out where this memory growth comes from. Please see below. From what I can see, CFString takes up a huge amount of memory. It doesn't appear to be from my code(based on StackTrace of CFString) as seen in Figure 2.
Please can someone advise? I'm really stuck. My app is crashing after a few minutes of scrolling after exceeding around 2GB of memory. I would appreciate any general pointers on how to debug the origins of the memory issue. The CFString stack trace appears all grayed out and I'm not sure how to proceed to diagnose the issue.
Figure 1
I am looking at CFString and the persistent memory is huge.
Figure 2
Clicking on CFString:
Try using the Instruments app, in the Xcode utilities folder. Specifically you want the Leaks instrument. It will find leaked memory, and then help you figure out where that memory gets allocated.
Run your app for a while, then break it and examine your heap.
(It's rather complex and tricky to use. Much more than I can explain in an SO answer. I suggest digging up a WWDC video or other tutorial on using it.)
There is also a simple memory graph tool in Xcode that flags leaked blocks, but it doesn't give you as much information. (It's one of the little icons in the debug bar above the debug console. The icon is 3 little circles with lines between them.)
In my app i'm presenting a ViewController which displays a GMSMapView. Neither the ViewController nor the GMSMapView are supposed to be dismissed until the app is on the foreground, so the GMSMapView object is never deallocated, and since i'm also showing a GMSPanoramaView, with both being pretty expensive objects, i'm having a performance issue related to high memory usage.
After the app launch, when GMSMapView is initialized, the memory usage is relatively low and totally fine for my app requirements.
The problem comes after i zoom in, i'm experiencing a high memory increase which is never deallocated even after i zoom out. I'm not sure, but it looks to me like something is being cached by the SDK and never freed.
In the image down below (testing device: iPhone XR), you can see clearly the issue, where the first peak occurs while i'm zooming and from then on memory usage never decreases even after the zoom level goes back to 0:
I'm trying to decrease the memory usage related to the cache(?) but i have no idea on how to actually do it or even if it is possible.
From my understaing from the docs, the .clear() method only affects markers and overlays. I've also notice the stopRendering() method that could have been useful, it is deprecated tho.
On a side note, to do some general performance improvements related to GMSMapView, i'm already setting the MapView property .preferredFrameRate equal to .conservative to reduce the rendering frame rate, and also setting .isBuildingsEnabled = false and .isIndoorEnabled = false to avoid useless caching.
My question is: using GoogleMaps SDK, it is possible to prevent the up above mentioned caching or to free the memory once the map is zoomed out? If not, is there anything else i can do to reduce the high memory usage related to GMSMapView?
EDIT: this might come in handy for someone else, thus i'm adding some more GoogleMaps SDK optimization tips. I'm using a custom map style and i've found out, from my personal experience, that using Cloud-based Map Styling (currently in beta) is a bit faster in rendering map tiles than the classic .mapStyle = try GMSMapStyle(contentsOfFileURL: file) approach.
After a bit of research, i've found out that there is an open issue regarding the high memory usage: https://issuetracker.google.com/issues/35826246.
This was opened 6 years ago, not sure it will ever be solved, shame on Google.
Not much else to do, apart from starring the issue and hoping for a fix.
I'm attempting to use the Memory Leak instrument in Xcode 4 with iOS 5.1 (ARC enabled) and I am spotting memory leaks, but how the hell do I get to the line of code causing the leak? I've read a few tutorials on this but it seems to be an older version of the instrumentation tool because when I click on the extended detail tab and double click on items in the backtrace I'm presented only with useless assembly code. Also none of the items on the stacktrace are any of the classes that I've written. Am I missing something?
If your code leaks memory, you will see your relevant methods in the details tab, right where you are looking. They are displayed in black as opposed to methods in the APIs which are gray. You can't look into API Methods of course, hence the assembly code. If there is really something wrong in your code, set the slider on the bottom of the tab on the rightmost position and you should see the concerned methods.
If still none of them are in your code, you probably just don't leak anything. (There are actually not many scenarios in which ARC-Code can leak memory. Retain cycles are probably the most common one) I stumbles over one or two cases in which an API was 'leaking' memory. There is really nothing you can do about it and most likely, it's just a false positive anyway rather than a real leak. If you are only 'leaking' a few bytes, I wouldn't worry about it.
When i draw a PDF i saw from instruments that if the CGContextDrawPDFPage method is not called from main thread, creates a leak in memory.
Someone has encountered the same problem?
Any help is appreciated.
It’s been a while, but I recall that the PDF functions involved a fair amount of lazy instantiation or caching. Is Instruments showing a true leak, or just allocations that don’t go away?
I remember getting concerned about memory bloat, until I realized it went away when I released the higher-level objects (CGPDFDocumentRef, I think).
I have a memory leak that is very puzzling! It happens when I tap the section Index and then scroll manually in a UITableView. It appears to be related to NSIndexPath, which I only read in didSelectRowAtIndexPath:indexPath. I don't create or store any NSIndexPath structures otherwise.
Other users had similar problem in earlier SDK versions and only within the simulator. I use the latest 4.2 and this leak appears both in the simulator and the device.
Below is a screenshot link. Any idea as to what causes this problem, or any tips on how to narrow it down without looking at assembly code?
http://www.maani.us/temp/Screenshot1.png
http://www.maani.us/temp/Screenshot2.png
Thank you.
I don't have an answer (yet), but I was wondering if you're still seeing this behavior. I randomly see the same thing as described here. I also realize that the Profiler isn't perfect, so I'm considering that too.