I have an application that uses the accelerometer. Sometimes, the application will launch without the accelerometer data updating. Relaunching the app, sometimes the problem persist, sometimes it doesn't. And even weirder, sometimes I can try 10 times and everything works as expected. Is this a bug, or maybe something I am missing. Debugging, this code is never called when the accelerometer is not updated:
- (void)accelerometer:(UIAccelerometer *)accelerometer didAccelerate:(UIAcceleration *)acceleration;
Any ideas?
I finally found a work around. This is a known bug. So the work around I found is to start a thread and have this thread check if the accelerometer delegate has been called, if it has, then quit the thread, if not, set the delegate again, and re-test, until the accelerometer delegate gets called. I tested this throughly and it works flawlessly. I hope this gets resolved on the next update of the iPhone OS.
I have this same problem. It happens perhaps 1/20 times with an app I made from the CrashLanding sample. After I noticed it with my app I grabbed a fresh version of Crashlanding, installed it, and finally got it to start with accelerometer failing.
I don't know how to fix it. Honestly I hate the accelerometer... at least for controlling games :-\
Also, the accelerometer has occasionally failed when I start the "accelerometer" sample project.
As others have mentioned, this is a known bug; I have logged the bug with Apple (Bug Reporter problem ID 6093028), perhaps others have done so as well. As far as I know, all apps that makes use of UIAccelerometer (including Apple's sample apps) suffer from this issue, though the frequency of occurance varies.
FWIW, my app is widely used and it uses the accelerometer, and I've never had this problem.
My use case may be different than yours: I only enable it on user request, well after the application is launched.
Related
Recently I've started porting my older Unity code with an earlier version of the Tango / Unity SDK to the latest version. Overall, it's working great. Faster frame rate, less drift, everything seems pretty good....Until: BLAM... Sudden crash. So, I tried paring down my app to the essentials to see if I could reproduce the crash and what I've found is that if I follow the AR Unity example in the docs to the letter, no problem. But, if I add a 'FindPlane' call within the Update() function so I place a sphere at the planeCenter of whatever is at 960,600 (middle of screen), after a few minutes the app will crash. So my suspicion is that this is what's causing the crash in my larger app (with many more moving parts, so to speak).
My question is two part:
1) can anyone suggest some debugging processes to help me identify exactly what the problem is here, in case it isn't the FindPlane function after all?
2) does anyone know why the FindPlane function might cause an error? Even if it doesn't successfully find a point it should still return Vector3.zero and a new/default Plane object, neither of which should result in a crash.
Thank you for your thoughts on this perplexing issue.
EDIT: I tried installing and activating Tango-Debug-Overlay recently and it shows a bit of diagnostic info. The problem appears to be thermal, and from what I can tell, related to the depth sensor. So now I'm trying to set a very low FPS, as a test, and disabling the depth sensor between frames, to see if that has any impact. I will post updates as I find out info.
Tearing my hair out on this, any thoughts or suggestions would be greatly appreciated.
I have an object that calls performSelectorOnMainThread:withObject:waitUntilDone: on itself from a child thread. This works fine 95% of the time. Every once in a while since iOS betas and now into release, a device will refuse to execute the performSelectorOnMainThread:withObject:waitUntilDone: calls... No error message, it doesn't crash, I can't make a device go into a state where it "fails" but once it's there it continues to fail until I either delete and re-install the app, or force it to quit, then adjust it's location services allowance, then launch it again, then re-adjust it's location services again back to normal... restarting the device does not fix it. Re-installing without deleting first doesn't fix it. It's very strange.... I know it works most of the time because most devices have no problems, however some devices fail somewhat regularly (every 3 or 4 days maybe). I know it's specifically that performSelectorOnMainThread:withObject:waitUntilDone: is not calling what it should because I've got a failing device now, and I've put an NSLog into the method that should be called. It function fine, but on the failing device, when performSelectorOnMainThread:withObject:waitUntilDone: is used to call that method the NSLog shows it's not being run...
This started happening with iOS 5 betas and again, happens on release. It happens most often on 2 of my devices, but on none of the other 10 devices I have personally tested on. I assumed it was just my device from some hiccup in the beta, but it happens on my brand new 4S which never touched beta, as well as on one user's iPad 2 (not on my iPad 2).
I really don't know where to look. I tell it to execute and it usually does on almost every device, but the same line gets no response and no errors etc. on some...
performSelectorOnMainThread:withObject:waitUntilDone can be wonky sometimes. Have you thought about trying to use lib dispatch?
You can create a block and post it on the main thread like this:
dispatch_async(dispatch_get_main_queue(), ^{
<do work here>
});
This would have the same save affect as using performSelectorOnMainThread:withObject:waitUntilDone
http://developer.apple.com/library/ios/documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationQueues/OperationQueues.html#//apple_ref/doc/uid/TP40008091-CH102-SW1
A Thread's RunLoop has several different modes.
It is possible that during the time you make your call the main thread is running in a mode different than the default one (which is the one targeted by performSelectorOnMainThread:withObject:WaitUntilDone:.
Consider using performSelectorOnMainThread:withObject:waitUntilDone:modes:
See Apple's documentation.
Also - GCD (libdispatch) is awesome, but it won't protect you from cooking yourself a deadlock:
Consider the case where your method is running on the main thread and you're calling:
dispatch_sync(dispatch_get_main_queue(), ^{
<do work here>
});
i made an iPhone app that uses camera. It works fine in iPhone, no memory warnings at all. It is also running on iPod touch 4G but gives memory warnings and crashes after some time after getting level 2 warning.
If someone can point me the possible reason for this. Thanks.
The only way you are going to fix this is by being able to debug it on the device. I wrote this blog to explain how to debug EXC_BAD_ACCESS, which is what I assume you are getting
http://loufranco.com/blog/files/Understanding-EXC_BAD_ACCESS.html
The simplest things to do:
Run a Build and Analyze and fix every problem it finds (or at least rewrite it so that B&A doesn't think it's a problem) -- Having a clean B&A is a really good way to making sure you catch these problems early
Turn on Zombies and run your program -- this makes the last release sent to an object turn it into a zombie rather than dealloc it. Your program will leak tons of memory, but if you ever send a message to a zombie it will stop right there and you will see a bug that you need to fix, because in your real version, that would be a crash (sending a message to a dealloced object).
More techniques described at the link
It crashes on a specific operation or randomly?
if randomly,
use instrument to check your memory leaks and memory usage. It's hard to figure out where the problem lies in without going through all your app.
Currently I'm testing an app that I've written with ios 4. I've spent a good bit of time looking for memory leaks and that side of things seems o.k.
I have a problem where the app seems to "randomly" quit after going from one view to another. Sometimes this will happen after a minute or 2 and sometimes it won't happen at all. Because of this it's really very difficult to determine where the flaw in my application is and under what circumstances because my observations of whats going on is subjective. Also it can get very annoying very quickly sitting there hitting buttons until something happens and then trying to remember the sequence of your actions.
What would be a good method to hunt down the cause of this seemingly randomly occurring problem?
For example,
I remember speaking with QA engineer before and he spoke of tools that he used to automate a user using an application. He'd leave it running over night and then in the morning he could examine what combination of user actions and under what circumstances a problem occurred.
Are there such tools available for testing iphone applications? Ideally what I'd like to see is a report of
action a
action b
action c
= everything ok.
action a
action c
action b
= there was a problem.
There's also fonemonkey: http://www.gorillalogic.com/fonemonkey
As for random crashes... I am tester, not developer, and random crashes are usually one of the topics I examine more thoroughly on every iphone app. My favorite scenarios are: leave the phone for 2 min, for 10 min, and switch apps (on iOS 4). In all cases it's better to use a real phone (and the older the better), not a simulator (some crashes never happen on simulator). Commonly nested views are affected (e.g. get to some view, let phone sleep, click "Back" button to return to previous view - crash). Usually developers say that incorrect retain / release, autorelease while another object holds pointer, and other memory issues are to blame. Also Device Logs (which will have crash report) usually can pinpoint problem pretty accurately.
Hey.
Instruments by Apple. Apple reference.
Instruments has its limitations and drawbacks, but just try it. It may be confusing at the begging so try to follow tutorial, or some other.
Check out running the app with zombies enabled. Also, instruments in Xcode is very helpful.
Hee
Does anybody know how to recognize a multitask-kill.
When the user puts the application in background state and then kills the app through the menu in iOS 4.2 my application shuts down.
Before there used to be an function called:
- (void)applicationWillTerminate:(UIApplication *)application
This method is not called anymore in iOS 4 and higher.
Is there a way to recognize it?
Thanks already.
Actually that's not entirely true. It is called on iOS4 devices that do not support multi-tasking and the documentation says that it can be called on other handsets (though I've never seen it myself).
But to answer your question, no, you can't recognise when a user kills your app. If you have state that you want to save you need to do this when your app goes into the background and not when the app is killed.
If you look at the crash reports you'll see that iOS sends SIGKIL which you can't catch.
You cannot catch this, your processed really is killed. Hard. Without notice. That us why you need to save state when you enter background now.
Maybe setting up a signal handler might work (don't know which signal to catch, though).