I have a super weird problem. Every time I run a specific bit of code in the iPhone simulator, my entire Mac freezes: I can't close the simulator, or any other app, and can't open any apps. Worst of all, I can't shut down. I have to force a shut down manually by holding the power button.
I'm running on a 15" MacBook Pro, and the only thing running is Xcode and the iPhone simulator. I used Activity Monitor to shut down any unnecessary apps running in the background. I've also used OnyX to clean up my system.
I'm using Xcode 3.2.4, with iOS 3.2 (iPad simulator).
At first I suspected this was a processor issue - so I ran the same code to induce a crash while I had Activity Monitor running. I can still switch between apps when frozen, I just can't open/close any or do anything with Xcode or the iPhone simulator. Activity Monitor reported that there was plenty of room for more processing, so it can't be that. I'm not running low on system memory. If I've missed anything out that might help in debugging this, leave a comment and I'll find the information. I want to fix this ASAP.
The code in question handles a bunch of timers, 3 background threads and a lot of UDP packets. The background threads are: two UDP receive threads, and a send thread. The background threads run a constant loop, looking for data on two different ports. The send thread runs another constant loop, but only sends data when there is any in its queue. The UDP processing just uses socket(), bind(), sendto(), recvfrom(), and select() calls.
I was under the impression that any problems in the current Xcode project would only become apparent in the iPhone simulator - an over-release only crashes the simulator, etc. How is it possible to crash the OS, not the simulator?
Edit: It runs perfectly fine on a device. Doesn't crash, doesn't report any memory issues, nada.
To see if a background thread is stuck on a blocked network call, put an NSLog (or fprintf to a file and fflush it) before and after every possible blocking call, and run with the debugger console visible.
Related
So I have an app that has twice been rejected from the app store and I really could use some help!
It has been rejected for the Watchdog timer forcing it to quit when it is first opened. However I have not been able to reproduce this on any of my devices. It does take a long time to build to a device when using xcode (i know that when built from xcode the watchdog is disconnected). But I have a couple questions that might help me fix this.
Does the watchdog take into account only didFinishLaunchingWithOptions: or are their other methods that it calls?
Does the number of frameworks used by the program have anything to do with it? and if so is 11 frameworks just too many?
Once the app is installed to a device, and I unplug said device is the watchdog timer re-enabled?
What are some other things that can add to the watchdog timer?
Apple said that another possibility could be Another possibility could be a missing entitlement. Could someone please explain what this means, I hav'nt seen this before with my other apps but thought maybe it was something new? And does it have to be installed on all apps for the appstore?
Time Profile for first seconds
You are blocking the UI thread for too long. To solve this problem, first you'll need to figure out what code took that long. It might be worthwhile to profile your app. Note that the simulator doesn't emulate the device, it only emulates the API. It could run much faster than the actual device because your computer is more powerful than an iPhone. Try click and hold Run at top left of Xcode, and choose Profile. Choose Time Profiler and run for a few seconds. Stop the profiler to analyze timing in function calls. Note that you may need to dig deeper, find some tutorials or books to really understand profiling.
When you know what parts have been running slow. You can put them into a thread. The easy way would be to use Grand Central Dispatch. To get started, visit this tutorial. You can skip the first half and focus on the actual thread blocks. The APIs are dispatch_queue_create, dispatch_async and dispatch_release.
This will unblock your UI.
Do you do a lot of processing in
application:didFinishLaunchingWithOptions,
applicationDidBecomeActive,
applicationDidEnterBackground,
applicationWillResignActive or
applicationWillTerminate?
Things like multiple file access, loading/saving data, synchronous network access can cause your application to freeze on startup or when the user exits, and could cause the watchdog to kill your app.
This Apple Technical note suggests that the watchdog is only looking at the launch, suspend, resume and terminate user interface events, so I would say you should look into these first, and maybe post back some more details of what your app does in the methods listed above.
http://developer.apple.com/library/ios/#qa/qa1693/_index.html
11 frameworks is fine. I have used 11 in an app no problem.
If you start the app up by tapping the icon on the home screen then the watchdog timers will be active and monitoring your app. If you start the app up by hitting run or debug in Xcode, then the watchdog will not be monitoring your app.
I have an iPhone application I'm testing - I've just noted when testing it on a device that sometimes when I resume it (i.e. launch it again in the "multitasking" sense when I expect it to appear and continue on) the startup image appears. As if it totally restarted.
Would this be an indication of memory issue with the app?
Good question. I've noticed this as well and wondered also. It might not be this app that has an issue though, but other apps have required extra memory which caused the system to take memory from this app. Im not sure exactly because (if I recall correctly) the resumed app restarts on the screens it was on, so it didnt lose state. I wonder if in this case, iOS has unloaded some of the backgrounded task's code and its taking a bit of time to read the code back in, so it puts that screen up. However, if this was the case, then the app would really need to be idle and not active in the background.
Any thoughts on why this code runs slow on device but fast on simulator in iphone, I am making a game in cocos2d, and I am moving an object from one place to another , throught CCTouchBegan , CCTouchMoved, CCTouchEneded (ccp function) and after that I take the action on it,
can any buddy tell me what is the main issue to solve this problem,
The simulator is a simulator not an emulator. All the simulator really does is provide a window for running an iOS app. You'll notice that when you build for the simulator, the system architecture is set to i386. You're compiling for the Mac when you use the simulator. There's no memory restrictions, sandboxing etc. In fact, I think your app even shows up as it's own process.
That's why when you run it on the device, you get hammered. You just have to work on optimizing your code. The simulator is terrible. Just use your device for debugging, it'll save you the confusion. If you post your code, we might be able to help you speed it up.
Happy coding.
The basic hardware of the computer on which the Simulator runs and that of an iOS device are very different, from CPU clock speed, to instruction parallelism, to branch prediction, to cache size, to memory bandwidth, to memory available. The possible compiler optimizations might also be different, given the different ISAs. It's not uncommon for general code to run an order of magnitude faster on the Simulator on a Mac than on an iPhone.
There can be many reasons like (also) #simulator vs actual device
Low Memory can be the first problem as in your actual device as you will install different kinds of huge applications but in case of simulator you will not install t.
Low power problem as the actual device will be powered by battery and not like simulators which get constant power all the time.
Other application interfering with your application run cycle but in simulator you will hardly run any application while you are testing your application.
You cannot see the UserInterface(UI) as clear in your MAC as you can see in your actual device, so which appears correct may not be actually correct.
Application interfered by calls, in simulator this type of interference will never happen.
Ever since the first beta came out I’ve been trying to find out if “real” multitasking is possible — i.e. can you put a program in the background and have it hang on to a network connection indefinitely?
I’m thinking about IM or IRC apps, for example. I’ve compiled an app myself on iOS 4, and without changing a thing it appeared to stay running in the background, but for all I know it was just suspended to memory.
The docs say the best you can do is request up to 10 minutes, but in the developer presentation they showed off Skype sitting in the background and then notifying the user that a call was coming in. Does anyone know for sure how this all works?
It appears the answer is no. The API for Skype is a very special case, called the "voip" mode, and requires special behavior, such as marking the socket in use for VoIP.
You can receive alarm notifications in the background (such as time passed). The amount of time you are in the background running state is severely limited by the OS.
Android's background model is complete and in many ways much nicer.
Apple has a guide named "Supporting Multitasking In Your Applications" which you should be able to locate.
Apple's iOS 4 developer docs outline this all very clearly.
When your app is closed or switched away from, it is almost immediately "suspended", meaning the OS freezes the app's state. When the user switches back to your app, your code keeps running just where it kept off. You don't need to add any code to your app to do this, just compile it against OS 4.
The above is true in most cases. There are two reasons the "suspended" model may not apply:
1) If the device starts to run low on memory, the OS will start terminating suspended apps that haven't been switched to in a while, without warning. This is why it's in your best interest for your app to remember it's state as well, so if your app is terminated, then re-opened, the user doesn't really notice because it still returns to right where they left off.
2) Your app uses one of the "background" APIs. These are for audio playback, VoIP services, or location services. In this case, your app is allowed to continue running in the background but only has access to those APIs. Additionally, your app can designate certain long-running tasks as "background tasks" that need to be completed before the app is suspended or terminated, like uploading pictures to Flickr or rendering a video, etc.
The "background task" method doesn't cover pinging servers indefinitely, as there is a time limit for the task, after which it will be forcibly halted. Apps that need that sort of functionality are expected to implement push notifications, just as before.
That should clear this up. All in all I think it's a pretty elegant solution to multitasking on a mobile device.
iOS 4 applications can either be running or suspended. The operating system will try to keep as many requested applications as possible in memory, while all other applications are suspended.
Applications that run in the background can access features such as navigation, audio, and VOIP (but NOT instant messaging). So it looks like you might be out of luck.
-- PC World Multitasking on Apples iPhone 4
It is possible for apps to request background time. Read the docs. I would say it iOS is "controlled multitasking".
You can create a long running background task, I believe these can include networking features. Just have to set the background task flag on the work block.
https://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
the OS can limit exactly how much time you get though... it will tell you when your time is up giving you a chance to cleanup nicely.
iOS 4 has "real" multitasking to some extend. There are two things to consider:
The UI event loop is single tasking. So only the front app executes on the UI event loop. Not a big deal: detach your main code form the UI event loop (maybe you need to redesign your app).
The OS "may" terminate your app if some criteria are met (e.g. low memory).
Currently one of these criteria is that execution time is limited to 10 minutes (real time not cpu time). However I expect this to change and see better criteria for background app termination (I hope to).
Apart from this you can have timers (event loops) in background.
There is no real multitasking in iOS 4.2 even. because apps will only be allowed to finish the task related to states..for small interval of time and then it will be in suspended state.. If you will set background task for long interval of time then... it will behave unexpectedly like no method will be called when you will try to run the app from anywhere..
You may be interested in this blog post that outlines how "multitasking" works in systems such as iPhone OS 4 and Android.
in fact u can do this, although it's not allowed by Apple. u gotta set up a toolchain in ur mac and use some unofficial SDK...
check http://code.google.com/p/iphone-backgrounder/ for more information
You should use the Push Notifications framework for the feature set you are creating!
I recently had an app rejected from the app store because of Low Memory Exception. The app doesn't leak memory, but its base memory footprint seems to be too high. According to the crash logs sent by apple, it was taking about 14000 pages in the memory (mostly due to huge textures). There were 2 strange things though:
I tested it on 5 devices rigorously before submitting, and never got this crash on any one of them.
I did optimize the textures after the rejection, and brought them to about half the original size (texture memory consumption).
I have no way of knowing how many pages my app is taking now, unless I can reproduce the same crash as apple (which I never could). Is there another way to be able to find out the memory footprint of my app, so that I can be sure that it is optimized enough now.
I did try instruments, but my app crashes when I try to run it through my XCode (must be some problem with my XCode). But it works perfectly when I run it directly on my iPhones/iPods. Any help in finding out the memory footprint of my app on iPhone (if there is something analogous to task manager of windows), would be appreciated.
Thanks
EDIT:
Launching the app from XCode gives the following error in the console:
"Error launching remote program: failed to get the task for process 553."
Launching the app with Activity Monitor gives the following error:
"Target terminated too early to collect data"
EDIT2:
I was able to run my app with Activity Monitor, by using a dev profile instead of distribution profile. But now there are several sections in the Activity Monitor - Physical Memory Used, Real Memory, Virtual Memory. Which one of these do I consider. To sum it up, I need to know which one of these causes the iPhone to throw a Low Memory exception.
XCode -> Run -> Run With Performance Tool -> Activity Monitor.
If the device is connected, Activity Monitor runs on the iPhone/iTouch.
I think you're coming at this from the wrong angle. You're asking how to find the memory footprint without using XCode. I think the question you should be asking is: why can you not use XCode? Presumably that's what you used to develop the application in the first place?
Without XCode you're pretty much flying blind. You say you halved the size of your textures, but how do you know? Does your app release any extraneous memory when it gets a low memory warning? (applicationDidReceiveMemoryWarning:)
First, have you looked at the crash logs from when you run your app from XCode? You should be able to see them in the Organiser in XCode.
I'm not sure there's a single solution to stop your app crashing with XCode. Normally when my iPhone won't allow debugging I just restart xCode and my handset and it starts working again. Restarting XCode sometimes helps. I would also try reinstalling both XCode and the iPhone SDK.