My app uses NSTimer variable which uses NSNotificationCenter.postNotificationName to post notification to UIViewController class every seconds.
The issue is the app crashes once in a while with no stacktrace which mean it is a memory issue.
From Instruments, it happens because a 1.78MB increase in VM:Allocation. The allocation just happens randomly.
Here is right after I start the timer:
Here is when I start the timer for a few minutes
So,
I don't see stacktrace or anything. How do I go about debugging
this?
The app use only 7.3MB and is in the foreground, why does it get
kill?? :(
I just leave the timer running, the method only updating existing
variables, what trigger this VM:Allocation???
I use Swift, if that matters
Thanks,
Turn out the problem is in the for loop. I had a big for loop that do a lot of assignment, calling API, etc, every time the NSTimer function is called so sometime when the number of iterations are a little bit too high the VM Allocation kicks in.
The answer I believe is to use autoreleasepool {} inside the for loop. No crash has happens ever since.
Watching these WWDC2013 video helps a bit in term of ideas but not directly.
Improving Your App with Instruments
Intermediate Swift
Related
My app gets stuck for a specific operation and that operation is too big having so many method calls and services requests, so i cannot put breakpoints on each method and debug, is there any other way i can get to know where exactly my app is stucked in xcode?
The operation wasn't too big to write the code, so it isn't too big to add breakpoints, logging statements, assertions and so on.
The only other way that works sometimes is taking a long shower in the morning, not thinking about work at all, and suddenly the realisation what you did wrong jumps to your mind. It has worked for me sometimes, but the first method is more reliable.
If you have reason to believe that the most time is spent in one operation, just let it run with the debugger attached and then press the pause button and see where you are...
A somewhat niftier approach would be to start with Instruments (i.e. the Time Profiler). It's easy to use and should be the first weapon of your choice for performance issues.
You can set a conditional break point in Xcode to debug a specific condition, for more detail go through Jeffrey Sambells blog!
Problem I'm trying to solve: My program uses System.Win.ScktComp.TServerSocket to communicate with another local process via Ethernet. Between receiving a packet from the local process and sending a response is 100ms--which shouldn't take this long. I'm trying to step through my program with the debugger to see where that 100ms is being spent.
The problem is that if I get the current time while I'm in the debugger it will obviously count the time it spent in the paused state of the debugger. Another problem is that the relevant part of my app is TTimer and event-driven so that when a routine returns you're not sure what routine will be called next.
My attempt: I can forgo using the debugger and print the current time everywhere like in all the OnTimer procedures and other events.
Much better solution: Step through with the debugger, getting the CPU time (which isn't affected by the time spent paused in the debugger) here and there to pinpoint where that 100ms is being lost.
I don't believe that you are tackling your problem the correct way, and have made that point in comments. Leaving that aside, the function that you are asking for is GetProcessTimes.
I'm trying to ... see where that 100ms is being spent.
A debugger will not be able to tell you that very easily. You need to use a profiler instead, like AQTime or similar, and let it clock your code in real-time and report the results, such as how much time was spent in specific functions and class methods.
I had a rather interesting exc_bad_access crash today. After a lot of digging, I came up with the following information (running in simulator):
If I just ran the code, the app would randomly crash at a random point while loading data into my managed object. From what I could tell, it was always crashing when I loaded data into the managed object -- not on the sections that converted from my JSON dict to data to the object actually used (from strings and NSNulls to ints/floats and nils)
Random crashes are, of course, evil, so I tried to step through the process in the debugger, but that didn't prove practical -- I was processing a LOT of objects, so stepping through them one-by-one just didn't work. So I decided to add some NSLogs to track the process and try to spot a pattern that way.
Instantly solved the crash.
Just one NSLog, anywhere in the process, prevented the crash.
I eventually tracked my way up the stack trace and found the actual issue: I was accessing the managed object in a threaded environment, but NOT from within the associated MOC's performBlockAndWait: method. At that point, the crash was incredibly obvious to me -- I'm shocked I didn't have more issues earlier. I'm willing to bet that between having a 'small' test data set of 2-3 objects and having debug code in there with NSLogs, the error was pretty effectively masked earlier... but the question remains:
Why does an NSLog prevent the app from crashing? How on earth could a piece of code without side effects change the execution of the rest of the app? This makes no sense!
Amazingly enough, this is a fairly common situation: I have seen it more than once when enabling logging in a seemingly unrelated place would instantly solve a timing issue somewhere else.
The reason for this is that NSLog, just like many other output functions, has internal synchronization. There is a mutex somewhere that protects access to the internal buffers of NSLog, either in the NSLog itself or in one of the I/O libraries that it uses. This synchronization enables callers to use NSLog from multiple threads. It is this synchronization that changes the timing of your program, affecting a race condition and ultimately solving a crash.
Why does an NSLog prevent the app from crashing? How on earth could a
piece of code without side effects change the execution of the rest of
the app? This makes no sense!
Indeed this makes a sense. Really.
A single NSLog forces to print something to your console, it takes some fraction of seconds and in between your processing on somethread gets finished and the crash (might be due to un-availability of input is) no-more.
Your error may be due to async call. Your next process starts before finishing previous one. And your next process need data from previos process. NSLog consumes some time.
I thought my app was almost ready to ship, but this one thing is making me crazy!
In my didEnterBackground handler, I save some images to cache and dump everything I can possibly think of and the OS seems to randomly dump my app and restart it. It doesn't seem to be very consistent. Sometimes it comes back fine and sometimes I get a restart. According to Allocations, my memory usage is down to around 1 or 2 mb in my didEnterBackground.
And by dumping everything, I mean I remove subviews, remove objects from arrays and set a ton of stuff to nil...which means in my willEnterForeground I have to recreate a bunch of stuff.
I really don't know what else to do.
Any help here would be greatly appreciated. Thanks!
BTW, this is in iOS 5 and using ARC.
At the background state the app can always get killed by the watchdog. There is no guarantee that the app is always working in the background.
To learn more about Multitasking watch the Session 320 from WWDC 2011 there is a plenty of information about multitasking.
OK, this one has me stumped. I use the CLLocationManager services (iOS 4.1) in my application. The delegate gets called as it should at first. Then (some arbitrary time interval later), the delegate stops getting called. It almost looks like that RunLoop is getting blocked somewhere.
I have even reduced the callback to one NSLog statement, and I see the same behavior. Do we have any gdb experts out there who could give me some hints how to look at all of the running threads, and determine which one is blocked where ?
As a test, I have also put a button on the GUI which stops are starts both heading and location updates - this seems to unjam things for a while.
Other info:
This is on an iPhone 4, app has been run through Instruments (leaks and allocations), everything looks good there. Any hints would be appreciated, I am currently out of ideas...
Mea culpa... I had errant logic which was firing a timer, shutting off the service. One again, caution is called for when making supposed "small" changes. My apologies if anyone wasted effort on this one....