My project doesn't use ARC and support iOS 4.3+, used Parse,Crashlytics framework.
I tested by Instruments about leak memory.
This is result. The problem is that all thing is in library system. Nothing is related to my code.
How can I fix them? Somebody help me!
Click to see fullsize http://i.stack.imgur.com/ZRrkQ.png
You application started a system thread shown in Instruments. It is not clear how. The thread doesn't call your code directly. It is somehow related to private DataDetectorsUI.framework; that calls CFStringTokenizer... You do not create this thread directly, you ask iOS to do something. Can you guess what is that and what part of your code triggered spawning the thread?
What are trying to do? Is it possible that you do not close the task properly?
DDOperation is a NSOperation subclass that is part of the Data Detection framework in iOS and OS X. I can't pinpoint your leak to a specific line either, but it appears like you are leaking something that is created indirectly when you use NSDataDetector. Check if you are retaining anything when using the block based enumerator but never releasing it.
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
Why when I tests my controllers in Xcode everything is fine, but deinit methods are not called. Is it correct?
While app works normally, it is fine, but not for UITest target.
For complicated structures simulator allocate over and over more objects, and... do not deallocate it at all. So, quite often on slower machines the app sometimes quits without any reason... and tests cannot be fulfilled.
Using Xcode 8, iOS 10, macOS Sierra.
I can not answer your question definitively without seeing a sample of the test code, however, your case makes me suspicious of a couple things.
Basically what is happening is that the app is creating new processes for each test you run. A memory leak somewhere inside the code would be the first problem to investigate. If you are leaking memory, the testing framework spinning up a bunch of processes could cause the crash and allow that issue to fly under the radar during normal running.
Also, unless you are de-initializing the controllers explicitly through the tear down function in your test class, the process is generally just killed at the end of the test. If you want to test your reinitialization I would suggest explicitly triggering a tear down in the tests to test your memory allocation behavior. Also, the Xcode Analyze feature may be of use to you here.
If you could post a sample of your test code that would be a great help and I will edit my answer accordingly.
Make sure deinit is not empty.if its empty then it will never work.put whatever you need to deallocate and check whether its working or not.
My suggestion
better to use dealloc method rather than using deinit.
Update 2: I found a workaround which is to synchronize MOC deallocating and saving. Please see the updated project.
https://github.com/shuningzhou/MOCDeadLock.git
Note: I made it fail more aggressively. Don't run it on a real device!
Update: A sample project to demonstrate this issue.
https://github.com/shuningzhou/MOCDeadLock.git
XCode 6.2: Unable to reproduce.
XCode 6.3: Reproducible.
XCode 6.4 beta: Reproducible.
========================== The Issue ===============================
Our app randomly stuck on OSSpinLockLockSlow after upgrading to XCode 6.3. In our project, we used NSOperation and NSOperationQueue to fetch data from our server and used Core Data for data persistence.
This issue never happened before! You can see from the stack trace that no calls are made by our code. I am not sure where to start debugging this. Could someone provide some guidance?
Thank you in advance!
Please see the stack trace
Edit:
We are using AFNetworking and our NSOperations are subclasses of AFHTTPRequestOperation. We added some custom properties and overrode the method -(void)start:
- (void)start;
{
//unrelated code...
NSString *completionQueueID = [NSString uuid];
const char *cString = [completionQueueID cStringUsingEncoding:NSASCIIStringEncoding];
self.completionQueue = dispatch_queue_create(cString, DISPATCH_QUEUE_SERIAL);
//unrelated code....
[super start];
}
For Core Data, We are following the thread-confinement pattern. We have separate managed object context for each thread, and the contexts share a static persistent store coordinator.
Edit 2:
More info: I found that this issue happens when the system exits multiple threads at the same time. We store the Managed Object Context in the thread dictionary, and they get released when the threads exit.
[[[NSThread currentThread] threadDictionary] setObject:dataManager forKey:#"IHDataManager"];
CPU usage is around 20%.
I have been experiencing precisely this issue. As per your stack trace, I have a bunch of threads stalled with _OSSpinLockLockSlow.
It appears to be a livelock situation with the spinlocks chained up together. Including some networking threads and core data. But as Rob pointed out, symptoms of livelock should include high CPU usages (spinlocks are all endlessly spinning). In my case (and in yours) this is not the case, CPU usage is low - simulator 'percent used' 20%, simulator overall in activity monitor 0.6% - so maybe it's a deadlock ;-)
Like you, I am using a thread-confinement pattern, separate managed object context per thread, single persistent store.
Following your observation that the hang always seems to follow deallocing of a bunch of threads, I checked that behaviour and can confirm that is the case.
This got me wondering why I had so many threads active. It turned out I was using gcd with a concurrent background queue:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND,0),^{
modelClass = [WNManagedObject classForID:mongoID];
dispatch_async(dispatch_get_main_queue(),^{
...
});
});
This snippet is part of some networking/JSON parsing code. 'classForID' was causing slight UI jitters on the main thread, so I backgrounded it.
In effect the concurrent background queue was spitting out a whole bunch of short-lived threads. This was completely unnecessary. Refactoring as a single serial queue fixed the thread excesses, which got rid of the spinlock issue. Finally I realised I didn't need to get the class at all, so this code has since been exorcised.
Problem fixed, but no explanation as to why this should suddenly become an issue with 8.3
I suspect that the same issue is touched on in this question (although Cocoalumberjack gets the blame there):
syscall_thread_switch iOS 8.3 race - CocoaLumberjack bug? how to debug this?
..and in this Cocoalumberjack bug report
https://github.com/CocoaLumberjack/CocoaLumberjack/issues/494
I am also using CocoaLumberjack but it does not feature in any of the problem threads, so I think that is a red herring. The underlying cause seems to be excess thread creation.
I have seen the issue in the simulator and on devices when tethered to XCode, but I have not experienced it when running independently of XCode. It is new to me in iOS 8.3 / XCode 6.3.1
Not really an answer, more of a diary of my own workaround for this weird issue, but maybe you'll find it useful.
If question is still actual - this is a bug in iOS: OpenRadar crash report
Also you may find this blog post useful: blog post
I think you should replace OSSpinLocks with something else to fix this in your app.
We encountered this bug in our Unity3d game. We didnt fixed this yet in our app because we do not have access to most of the native iOS code (we write our game on C# and we use a lot of 3-rd party native plugins). So I cannot recommend you something concrete about replacing OSSpinLock. Sorry for my English.
Update
Many Apple frameworks and libraries uses OSSpinLock internally, so you dont need to use it explicity to run into this issue.
I'm trying to debug an EXC_BAD_ACCESS crash using NSZombie. My app creates lots of large objects though and with NSZombie enabled they aren't getting released causing the app to crash in seconds. This means I can't even cause the EXC_BAD_ACCESS crash before the app crashes due to low memory.
Is there an alternative? Can I enable NSZombie on specific file instead of the entire project? How else could I debug this crash (I know it's caused by UIGestureRecognizer but I use them a lot so it doesn't narrow down the issue significantly).
Thanks.
Edit:
Thanks for the advice. I think I may have solved the issue and will report back after more testing.
Edit 2: Sovled the issue myself but selected the answer which seems like it would be a good solution to any similar issues in the future.
All I can think of is implementing it manually; create a proxy container that holds an object of type id and nominates that as -forwardingTargetForSelector: as well as getting it to respond to -isKindOfClass:, etc.
Disable ARC for the proxy and have it retain itself during init and check its own retainCount when nominating a forwarding target.
If the count is 1 then raise an exception or log a warning or whatever.
Have suspect classes wrap themselves in and return a proxy as the last line of their unit.
For possible bonus points, store [NSThread callStackSymbols] somewhere (probably on disk) during the proxy's unit so you can at least find out where the incorrectly managed object was created.
NSZombies was/is for apps that use their own memory management. If your app uses ARC then this won't help.
Create a new Breakpoint: All Exceptions
That should usually show you where you trigger the bad access.
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.