- Home /
Android app crashes after 15 mins of play. Too many open files.
Any idea on this? Any help would be greatly appreciated.
Unity 3.4 Android Basic, Galaxy S. The game is a simple one, more like a picture viewer. It has some buttons (cubes), UI elements (labels) and a very simple AI. It does have save game functionality, but only when the player advances a level.
After playing around 10-20 minutes it blinks (or not even blinks) and whoops it disappeared. (Crashed eventually.) In case of every 'death' the game was cc. idle. (I was thinking.)
adb logcat has the following not too verbose information (//comments by me)
I/Unity (13928): UnityEngine.Debug:Log(Object) //Debug.Log...
I/Unity (13928): msgAPI:setText() //setting the label of a text in msgAPI script
I/Unity (13928): msgAPI:FixedUpdate() //msgAPI's FixedUpdate function
I/Unity (13928):
I/Unity (13928): (Filename: /Applications/buildAgent/work/8xxxxxxxxxxx52/Runtime/Export/Generated/UnityEngineDebug.cpp Line: 34)
I/Unity (13928):
E/dalvikvm-gc(13928): Could not create 1196032-byte ashmem mark stack: Too many open files**
E/dalvikvm-heap(13928): dvmHeapBeginMarkStep failed; aborting
E/dalvikvm(13928): VM aborting
D/Zygote ( 3172): Process 13928 terminated by signal (11)//Dies
I guess the culprit is somewhere around the "too many open files" error. But what could this mean? I only have textures loaded via the editor (ie no streaming assets). So ok maybe it's due to some parts of the program... but... I only user primitive variables, a few classes and a few built-in arrays.
Also... objects are not created in any of the Update/FixedUpdate functions, the only problem I could imagine if I created objects too fast (like in an update) and the GC couldn't deal with it.
PS.: One thing came to my mind. Is it legal to use renderer.material.SetTextureOffset("_MainTex", somethingVector2) at will? Or does it go into file reading when called?... Erm, I'm out of ideas atm.
Update: I wrote a script so my PC played the game in the Editor's Play window. The game ran w/o errors for 1 hour+. Now I'm puzzled.
If you are not opening files (including network accesses), then I'd suspect a bug in Unity that you're tripping with something novel that you are doing. If you can narrow down what you're doing, Unity would probably love to have the bug report.
Certainly changing the texture offset is not unusual, so I'd not suspect that. Does it crash if you don't actually play but just sit there idling in the game (you may need to change your game rules to test that of course)? If so, that narrows it down to just the update functions that would be executing while idling (such as your suggestion about the UV animation).
One thing I'd suspect: do you change a PlayerPrefs variable all the time? You should be allowed to of course.
Another thing I'd suspect is logging. Try to get rid of any continuous logging (you should do that anyway), to see if that fixes it.
Thanks for the comment, I will try to eli$$anonymous$$ate the many Debug.Log calls, and no it doesn't crashes on its own (without actually playing) and no I don't change the PlayerPrefs variable at all. I will let you know what happened, thanks again.
UPDATE: It DOES crashes when leaving idle and setting the display to never sleep. Thanks for the tip, will post more updates later.
Sigh. It looks like that leaving the game on its own even on the splashscreen level reproduces the same phenomenon.
FYI the splash screen level has like zero code. Update 2: Tested it with my test unity project, it dies after 20 $$anonymous$$s too. Now testing it with Papertoss to see if my telly is the culprit.
Papertoss didn't crash. It seems my phone doesn't like Unity or vica versa.
Answer by splash28 · Aug 15, 2011 at 01:26 PM
I think I've found somewhat of an answer. It was (is) building in development mode. (Player settings.)
For some reason even the simplest project crashed on my phone IF it had something to do with textures. Ie. make a cube, put a texture on it, take a Texture2D array with around 12 textures and 'animate' it with this:
var frames : Texture2D[];
var framesPerSecond = 10.0;
function Update ()
{
if (Input.GetKey(KeyCode.Escape)) Application.Quit();
var index : int = Time.time * framesPerSecond;
index = index % frames.Length;
Debug.Log("index == " + index);
renderer.material.mainTexture = frames[index];
}
On my Galaxy S it will always crash after 15-20 minutes if you build this project w/development mode on.
Are you sure that isn't because of the 36000 Debug.Logs (if it gets 60 FPS)? Presumably they are a no-op in a non-dev build.
I will test that too, ty for the tip, but since it's 2 am here, that's work for tomorrow. :)
I've tested it and the app, compiled with one scene, with one script in it
function Update()
{
if (Input.Get$$anonymous$$ey($$anonymous$$eyCode.Escape))
{
Application.Quit();
}
}
dies after cc. 20 $$anonymous$$utes if it's built with development mode. Anyway, non-dev mode was an adept workaround for me.
Your answer
Follow this Question
Related Questions
Invalid Indirect reference in decodeIndirectRef. VM aborting. 0 Answers
Android build crashes on launch. 2 Answers
Unity 2017 frame rate capped? 2 Answers
Unity crashes without debugging 0 Answers
Debugging an Android device from Visual Studio 2019 2 Answers