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.
Related
while a simple mobile unity game project (or a simple project with a cube and a camera) provides almost uniform CPU time with less variation while profiling it.
But adding the googleVR (tried latest and old versions) module to it, split into left and right eye (GVRviewer) and profile the VR mobile app provides a lot of spikes or variations which is due to VR.waitforGPU() and in turn gfx.processcommands(). can anyone please tell me what's the reason behind those performance spikes while adding GVR module ?
I have tried multiple optimizations (e.g. static batching, disabling vsync, optimizing mesh data) but nothing seems to be useful. Is there any possible way to get rid of this issue?
I am working with VR and found a big problem in step one. I followed the most basic tutorial and everything works fine until I try the app on my phone.
Even though the scene is extremely basic (just one plane, medium quality settings) there is a huge delay between the movement of the head and the app responding. I have a total amount of 2 Draw Calls, 2 Batches, 1.9k Tris. Frame rate on pc is 4000 Fps!. So it definitely is not an optimization issue.
I have unity updated to 2017.2.0f3 and GVR is version 1.100.1. My phone is a Huawei P8 Lite 2017.
Why is this happening?
I am not sure what tutorial you followed but it shouldn't have this issue. My suggestion is begin an empty new project, import GVR SDK and try to build the DEMO scene... check out if this works fast or slow.
When I got started in iOS dev, debugging in Xcode seemed like a pain. I used to get exec_bad_access issues & crashes at random points that took me ages to figure out the reasons behind.
I then stumbled upon Brad Larson's videos on debugging in Xcode and my life has never been the same. He showed how you could dynamically set a break point & get your app to break every time an exception was thrown. This allowed me to actually see the stack trace & figure out what was wrong in a jiffy. It made life a lot easier.
To the experienced developers out there, are there any more random tidbits such as this that you find useful?
SO itself is a nice resource:
Hidden Features of Xcode
How to print out the method name and line number and conditionally disable NSLog?
Memory leak detection tools
I have built my first game using Cocos2D. It worked fine on the simulator. But when it runs on the actual iPhone, it crashes. I don know why. Thought it was memory leaks, so i tried to detect, but no leaks found. I tried to increase and decrease frame rate, neither both succeeded. Anyone experienced please help me out. I am really stressed now. If anyone had the same issue please share with me your opinion.
Yours thanksfully.
I've run into similar issues (I also use Cocos, but I don't think this is Cocos specific). The best thing to do is plug-in your iPhone and watch the stacktrace when it crashes (or retrieve the stacktrace after the fact)
This happened to me a lot because the resources between the iPhone and the simulator were not in sync; in other words, some how resources would be available to the simulator (eg: images) but those same resources were not transferred to the iPhone for whatever reason. Sometimes, if I ran 'clean' on the simulator, I would observe the same issue.
It's extremely frustrating to debug these types of issues, but you'll get used to it.
I agree with Dominic - we definitely need more information to be able to help you - do you have the output from the console or the stack from the debugger?
Also, while memory leaks are a Bad Thing, they rarely lead to crashes directly. They will increase the amount of memory used by your app so if you're memory intensive then you might get a problem but they're not the first place I'd look to try to debug this.
Try running the app in Instruments and watch the memory usage graph - then not only can you see the total that your app is using but you can get an idea of which sections of your app use the most and can focus your efforts in reducing it.
Sam
Sorry, but you need to specify more details. How does it crash? What does the error log say? One thing you might look into is the amount of memory, your game consumes. If it uses more than 64 MB on the actual device, the OS will very likely just terminate it. In the simulator on the other hand, your app might use lots more memory without a problem.
I have found tools like Instruments and NSZombieEnabled to be very helpful in tracking down issues such as these.
Without more information, I would try the following steps:
Delete the app from the device and simulator (using the tap-and-hold technique to make your icons jiggle) and reinstall it. Sometimes a setting (or lack of a setting) in the user defaults will cause a crash, and those don't get wiped out unless you delete and re-run your app.
Also try the "simulate memory warning" option in the simulator and see if that gets it to crash.
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.