My assumption is that the red line is the culprit for why my object is still retained. Is that the case? Where can I go to find out more information about this line?
The red line is telling you that 90.4% of the memory allocated in the current method is allocated in the call to fadeOutSplash. Whether or not that line of code is causing your object to be retained can't be determined from the view in your screenshot.
If you look at the screenshot you can see an Info button next to the 90.4% listing. Clicking the button will show you the heaviest backtraces, the backtraces with the largest memory allocations. I'm not sure how much that information will help in your case, but it is additional information about that line of code.
Related
I'm making a Swift 2.2 app in XCode7.3 using SpriteKit & GameCentre.
My issue is the memory used by the app continues to grow (an additional ~20MB is grabbed every second or so). Eventually this causes the app to crash due to memory issues. I get similar results running on a device (iPhone 6s) & simulator.
I've had a go at running it through Instruments (screenshot below) and this seems to show the issue.
Instruments screenshot
From digging into the instruments output, it seems to show a memory leak occurring off a 460 KiB malloc call. I haven't manage to isolate what's causing this from the stack trace.
Instruments output available - not certain how to attach it here. Any suggestions / pointers on where to start?
Try binary searching your code. Comment out half your calls. Still getting a memory leak? Ok, now you've reduced your search scope by half. Comment out half of the remainder. No memory leak? Great, you've just narrowed down your problem to 1 quarter of your code. Once you start getting the specific code that is causing the leak, you'll get much more useful answers out of StackOverflow.
Answer has been found - cause is a bug in the Apple/Spritekit code.
As part of setting up the scene I was setting showFields of the SKView to true. Once I disable this (false) the memory leak issue goes away.
From searching for this I found - https://forums.developer.apple.com/thread/27870
Im experiencing memory leak on static menu scene, it appears that it happens on every scene, game scene itself but also static menu/gameover. Memory appears to be deallocated correctly (and it's reduced when scene is gone).
Those static scenes does not conatins even update callback defined.
It's all setup in didMoveToView and inside it there are couple SKLabelNodes and SKSpriteNode allocated with spriteNodeWithImage.
I have tried to use dealloc to monitor if scene got's deallocated correctly, and it appears to be so it seems it's not the source of the issue.
Browsing google pointed me to some other threads created on stackoverflow that
spriteNodeWithImage
textureWithImage
May cause
-Memory leaks
-weird error "CUICatalog: Invalid Request: requesting subtype without specifying idiom"
So i have tried to create UIImage imageNamed and then put in into texture and use in SKTexture, actually it has removed CUICatalog error (which anyway, seems like a stupid message which did not been removed by apple - can anyone confirm that ?)
But according to memory leaks this didn't help at all, and anyway anything in that scene is being created once on beginning so i have no idea why this memory keeps growing and growing like 0,5mb per sec.
Looking forward for any tips.
Best regards
Actually i have found the source of the problem.
It seems debugging physics makes huge memory leak
skView.showsPhysics = YES;
It's not a big problem since it happens while debugging only when showsPhysics=YES.
But good to know anyway.
My application performs several rendering operations on the first frame (I am using Metal, although I think the same applies to GLES). For example, it renders to targets that are used in subsequent frames, but not updated after that. I am trying to debug some of draw calls from these rendering operations, and I would like to use the 'GPU Capture Frame' functionality to do so. I have used it in the past for on-demand GPU frame debugging, and it is very useful.
Unfortunately, I can't seem to find a way to capture the first frame. For example, this option is unavailable when broken in the debugger (setting a breakpoint before the first frame). The Xcode behaviors also don't seem to allow for capturing the frame once debugging starts. There also doesn't appear to even be an API for performing GPU captures, in Metal APIs or the CAMetalLayer.
Has anybody done this successfully?
I've come across this again, and figured it out properly now. I'll add this as a separate answer, since it's a completely different approach from my other answer.
First, some background. There are three components to capturing a GPU frame:
Telling Xcode that you want to capture a GPU frame. In typical documented use, you do this manually by clicking the GPU Frame Capture "camera" button in Xcode.
Indicating the start of the next frame to capture. Normally, this occurs at the next occurrence of MTLCommandBuffer presentDrawable:, which is invoked to present the framebuffer to the underlying view.
Indicating the end of the frame being captured. Normally, this occurs at the next-but-one occurrence of MTLCommandBuffer presentDrawable:.
In capturing the first frame, or activity before the first frame, only the third of these is available, so we need an alternate way to perform the first two items:
To tell Xcode to begin capturing a frame, add a breakpoint in Xcode at a line in your code somewhere before the point at which you want to start capturing a frame. Right-click the breakpoint, select Edit Breakpoint... from the pop-up menu, and add a Capture GPU Frame action to the breakpoint:
To indicate the start of the frame to capture, before the first occurrence of MTLCommandBuffer presentDrawable:, you can use the MTLCommandQueue insertDebugCaptureBoundary method. For example, you could invoke this method as soon as you instantiate the MTLCommandQueue, to immediately begin capturing everything submitted to the queue. Make sure the breakpoint in item 1 will be triggered before the point this code is invoked.
To indicate the end of the captured frame, you can either rely on the first normal occurrence of MTLCommandBuffer presentDrawable:, or you can add a second invocation of MTLCommandQueue insertDebugCaptureBoundary.
Finally, the MTLCommandQueue insertDebugCaptureBoundary method does not actually cause the frame to be captured. It just marks a boundary point, so you can leave it in your code for future debugging use. Wrap it in a DEBUG compilation conditional if you want it gone from production code.
Try...
[myMTLCommandEncoder insertDebugSignpost: #"com.apple.GPUTools.event.debug-frame"].
To be honest, I haven't tried it myself, but it's analogous to the similar
glInsertEventMarkerEXT(0, "com.apple.GPUTools.event.debug-frame")
documented for OpenGL ES, and there is some mention on the web of it working for Metal.
First, in Metal, I usually use Metal to do parallel compute, then GPU Capture frame is alway grey. So, there are two ways until now I found is Ok.
In iOS 11
you can use the [[MTLCaptureManager alloc] startCaptureWithDevice:m_Device]; to capture frame so you can profile the compute shader performance
lower than iOS 11 (MTLCaptureManager && MTLCaptureScope are new in iOS 11.0 )
you can use the breakpoint, then edit the Action.Capture GPU Frame
Xcode 6 have some strange break point issue. I have removed all break points from my project but still its hitting some invisible break point every time.
I have tried below things.
Commad + 7 and delete all break points.
(lldb) br delete
error: No breakpoints exist to be deleted.
I don't see any break point but still its hitting some break point. see below screenshots for reference.
..Nitin
This is not a breakpoint, but rather an exception in the view controller (whose name you've partially redacted here). Click on that second item in the stack trace, and it will like show you the offending line. Just go up the stack trace until you get to your own code.
It's hard to tell on the basis of so little information, but looking at the stack trace, the assembly code shown, and the exception, it looks like you've encountered a problem during a segue where a cast failed. Perhaps have a prepareForSegue method that is trying to cast segue.destinationViewController to a particular view controller class in order to pass some data to the destination, but the cast failed for some reason. Perhaps you neglected to set the base class for the destination scene in the storyboard.
But if you click on that second line in your stack trace (right below the currently highlighted line) and you'll probably be taken directly to the offending line of code.
There don't have to be any breakpoints set in you project to encounter this kind of behaviour. It means that the thread was aborted because of a fatal error. You just can't see the code, because it happened somewhere deeper in the system, so the Xcode only shows you the assembly code.
As I can see from your stack trace, these threads could be related to your question:
swift prepareForSegue not working / exc_breakpoint (code=exc_i386_bpt subcode=0x0)
Don't know what this means Thread 1: EXC_BREAKPOINT(code=EXC_1386_BPT,subcode=0x0)
I have an iPhone app, that seems to have memory leaking problem. It's a puzzle game, after a few puzzles, the app crashes on devices.
I'm now trying to use xcode Instruments to detect what's going on. First time to use Instruments.
I noticed a leak bar in the "Leaks" plot, right the time when the view is loaded:
What are these memory leaking objects, detected by xCode Instruments?
. However these leaked objects are small, so I guess my app has other problems.
When my app continues to run, usually for 10+ rounds on an iPad 2, it then crashes. I don't much about Instruments yet, so I watch "All Heap Allocations". At the beginning of first round puzzle, the column "# Overall" is ~70k, it grows slowly between rounds of puzzles. When a new round puzzle comes in, it goes to ~90k, then round by round it reaches ~200k, then crashes.
Before crashes, in the log console I see memory warning and "CONNECTION INTERRUPTED".
I've followed a few things after searching memory leaking, such set NSArray/NSDictionary or mutable ones to nil, as much as possible (although not all of them, since some go between puzzles). I also changed UIImage imageNamed to [UIIMage alloc] initWithContentOfFile.
What else should I look/check to see what causes memory problem? TIA!
EDIT:
I wish I could post some codes that may be the suspect, but I really don't know what part to post. I should've check via Instruments in the course developing, so that I would know what caused the problem.
Regarding other view controllers. I do have others (menu, settings, app-store-rate, etc) and I generated all of them via code. My app doesn't have a storyboard or nib file. When I test crashes, I just click Next Puzzle button, so all other views will not show at all. So, before crash, the only view shown is the main view, with a few button, a few subviews, an animated pictures (but only the first puzzle as introduction). If it helps, here is my app:
http://itunes.apple.com/us/app/wordsect/id599455449?ls=1&mt=8
If you trying to debug application with Instruments - enable zombie detection mode:
In
Xcode: Product->Scheme->Edit Scheme
Select Debug scheme
Select Arguments tab bar on the scheme description
In Environments variables add and check NSZombieEnabled variable
Then when you start application under Instruments control, you'll get name of the instance, when your application crashed.