I've recently finished my first iPhone app that I'm actually planning to submit, and I'm trying to clear out all the leaks. However there's one that I just can't seem to track down, and Instruments isn't really helping me either. Essentially, I've made something like a to-do list app (that's not really important though) and every time a user deletes a to-do, instruments registers a leak.
Instead of me trying to explain further, here's a screenshot:
http://dl.dropbox.com/u/1426380/Screen%20shot%202011-02-09%20at%2021.51.09.png
So instead of telling my exactly where the leak is coming from (like with previous leaks I've fixed), iInstruments just points to somewhere in the foundation library. It's only leaking 16B each time, so it's not really an issue of crashing, but I'm simply interested as to what is causing this.
I would love to post some code, but since I have no idea where the leak is originating, I have no idea what to post. If someone had an insight on what might be causing this, I'd be happy to oblige.
Thanks.
EDIT:
Here's another screenshot as requested by #Moshe. I'm new to instruments so I didn't even realise that the right panel existed until now!
http://dl.dropbox.com/u/1426380/Screen%20shot%202011-02-10%20at%2007.55.58.png
I suggest running "Build and Analyze". (In the Build Menu, or ⌘ + shift + A).
If that returns nothing, it could be that an Apple framework is leaking. If that is the case, there is nothing you can do.
Related
Users are getting this crash in testing. My first guess was that it's memory-related but I don't have much more to go off of than that. Looking deeper into the code, I thought this might have been a Main Thread issue but it looks like listeners are removed on a background thread, so I'm skeptical that that's the reason.
I thought that removing any active listeners when the app backgrounds and re-adding them when the app foregrounds might negate this crash but it doesn't seem to have helped.
Any advice on how to fix this crash? Thanks!
Edit: I left the simulator open for long enough and I got this, which is probably the same crash.
Edit 2: Profiling with the Leaks Instrument didn't turn up anything related to Firestore. It only had 7 small leaks related to Foundation and UIKit after the app closed
Looks like this was introduced in 0.15.0 – https://github.com/firebase/firebase-ios-sdk/issues/2138
From time to time, Xcode Crashes comes up with a crash that i cannot understand. I pasted the xccrashpoint to gist
It states, that Thread 12 crashed somewhere in CoreGraphics called by CorePDF, called by QuartzCore drawing some layers. This seems like OS-called code, maybe via thread 1 which is doing _saveSnapshotWithName. So i assume, that this happens when closing the app.
Does anyone have at least a rough idea what is going on here? Maybe someone saw something similar before and can give a hint about what is crashing…
There is nothing special in the app that would cause dramatically wrong behaviour when leaving the app (-> when a screenshot ist taken).
Exec bad errors occur when an attempt is made to access a object or memory location which is not yet initialized.
There might be a problem with an object which you are not defining global.
Check if there is any object you defining and initializing in a method and trying to access out of the scope.
For more details related to errors and crashes, please go through below link.
http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-1
Since moving to iOS 8.3, I'm encountering this error where the main thread will get stuck in this call. A few other threads are also stuck in that call. There is none of my code in any thread that leads to this call, so I'm stumped as to why this is happening. It happens randomly, sometimes, when tapping a button bar item, sometimes while redrawing charts (using ShinobiCharts), etc.
Here is the stack trace from Xcode:
Anybody has any clue as to why this is happening and how to fix it? It's very annoying because when I get stuck there, I have to relaunch the app. Note that this is happening in the simulator so far. I'm in the early stage of developing this app and spend most of my time in the simulator. I haven't seen the error happening yet on a real device but, again, I haven't run the app that often on the device.
Knock on wood, but I think I figured it out (at least in my instance).
What led to the solution was a search for syscall_thread_switch, which led me to this answer here:
https://stackoverflow.com/a/30333203/978509
Which, if you look at the backtrace I linked (https://gist.github.com/Shalmezad/65ff89d20aa7e0a9d094), every syscall_thread_switch is preceded by OSSpinLockLockSlow, which the answer notes looks like Livelock, but due to the low CPU usage, is more evident of a deadlock.
Going through my code, I found that for every background task, I created a new dispatch_queue_t each time. I since redid how that works to use the same queue, which seems to have fixed the issue.
Without further information from nemesis (mainly some code snippets showing how he's setting up background tasks), I cannot answer their specific question, however this should point people in the right direction for fixing the issue.
I have a nasty retain cycle in my iOS app. I'm looking at it in instruments and can see all of the retains/releases, but it's hard to track down exactly which retain is the one still holding on.
Does anyone have advice for finding exactly which retain is holding onto the reference?
Edit: Picture of the retain/releases:
You could check out if instruments detects the leak, like so:
From the looks of it, though, that timer near the end of the list doesn't get released.
Could you update your post with the code in setVideoState ?
Edit:
What I usually do is try and match up the retain/releases (instruments should actually do that for you, i think it was some filter in the menu to the left), while focusing on my code, because the frameworks usually have their things together. In your case, as you go down that list you see that the timer has +1 but never get released after that.
I've seen suggestions saying to set NSZombieEnabled to true while debugging. What is NSZombie? Is it a framework? A setting?
It's a memory debugging aid. Specifically, when you set NSZombieEnabled then whenever an object reaches retain count 0, rather than being deallocated it morphs itself into an NSZombie instance. Whenever such a zombie receives a message, it logs a warning rather than crashing or behaving in an unpredictable way. As such, you can debug subtle over-release/autorelease problems without advanced tools or painstaking needle in haystack searches.
The name is a fairly obvious play on the fact that objects are normally considered "dead" when they reach retain count 0. With this setting, they continue to exist in a strange half-life - neither living, nor quite dead. Much like real zombies, except they eat rather fewer brains.
Adam did a great job explaining what Zombies are, but using the environment variable is not the best way to find and track these.
A much better approach to zombie detection, is just to use Instruments - from XCode start with "Run with Instrument" and choose "Allocations".
Then stop the recording right after it starts, press the "i" button on the Allocations instrument, and turn on "enable reference counts" and "Enable NSZombie Detection". Now hit Record again in the instrument, and your app will start up - if any zombie objects are sent messages recording will stop, and a dialog box will pop up in the recording timeline - you can click on that to find every place an object was retained or released.
Edit: Previous advice was for XCode 3, here's an addition for XCode 4:
In XCode 4.2, there's an even easier mechanism to make use of Zombie detection - the Zombie Instrument. Instead of "Run" to start the app, use "Profile" and an instrument selector will come up. Select "Zombie", and the app will start running - do whatever causes your crash, an a dialog will pop up saying "Zombie Messaged".
From there, click the small arrow in the dialog box. That will take to a list of all the times that zombie object was created, retained, or released. Pull up the side bar and you can go to each entry, looking at the stack trace for the code that was responsible for each adjustment in the retain count.
I agree with what Kendall added, it's very useful, but I'll suggest still doing the environment variable so you don't forget they're enabled. Similar to the (now expired) link at Cocoa Dev, I put this so I don't miss it:
if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled")) {
NSLog(#"ZOMBIES/AFOC ARE ENABLED!!! AAAAARRRRRRGH!!! BRAINS!!!");
}
It catches my attention very nicely.
Would help someone.
Detailed document on Instruments.
https://developer.apple.com/library/watchos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/index.html#//apple_ref/doc/uid/TP40004652-CH3-SW1