Hey there, Enda here.
So I’ve definitely fallen of the regular schedule of blogging, since the project has escalated and been incredibly busy! However, I plan to address a few different topics over the next few blog posts and catch up.
This post will talk about bugs and troubleshooting them, and this project has had more than a few, which led to some very despairing situations. Bugs are a daily reality in programming; if you’re lucky, when you find a bug, it’s something small and you immediately recognise what has gone wrong (mostly likely because you put it there in the first place!) However, on this project I have dealt with two ‘major’ bug problems, which were proving catastrophic for the project.
Bug 1: Easy Movie Textures
As mentioned in previous posts, I’ve been using a third party plugin, Easy Movie Textures, in order to create film textures on mobile devices. This is because Unity still does not natively support such a feature, although they really should! As a third party plugin, the behaviour of the asset is not entirely certain, and certainly lacks the robust testing that Unity’s native features go through. However, it took some sleuthing to even pinpoint the bug as an Easy Movie Texture issue.
The problem manifested in early builds. It appeared that UI buttons that moved the camera would stop working. This problem appeared in builds only and behaved as expected in the editor. My first thought was that this was a UI issue: we had already encountered UI problems with Unity and the GoogleVR SDK. The bug initially seemed to be random, but further examination revealed that it only happened after a video transition has been done – this was the first clue that it was something to do with the Easy Movie Texture asset. As it transpired, I was able to establish that the variable which contained the current state of the movie (ready, playing, stopped, ended) did not behave in builds as it did in the editor. In this case, it meant that the ‘if’ statement used to detect when the movie was over was constantly being triggered. This ‘if’ statement in turn triggered a function which moved the camera to a particular set of coordinates was also being constantly called. Forcing the camera to become stuck in one place. The next UI marker would move the camera when clicked, but only for a single frame, as it was then forced back to its previous location by the still running script.
The issue was reported to Unity, who recreated the problem but could not identify why. Thankfully, I was able to discover the solution to the issue myself in the end. This bug was an important lesson for me – it taught me that behaviours in the Unity Editor and in a build will not necessarily behave 1:1. As a result, I became more cautious and understanding of the difference between the two environments.
Bug 2: Crashing & Memory Leaks
This bug induced more than a bit of panic! As builds started getting bigger and bigger, we noticed that they would crash more frequently. Initially this was attributed to whatever the user was doing at the time, but eventually we noticed the app crashes regardless of what the user was doing – they seemed inevitable. By using the debug tool in Xcode, while the phone was hooked up, I was able to find some shocking numbers.
Unfortunately, our app was eating up the phone memory. I discovered that this is something called a ‘memory leak’, where something is constantly being stored into memory, but is unable to be dumped from it. When memory use hits a critical point, the app crashes in order for the phone to save itself for its basic functions.
I did a lot of testing with various kinds of builds, to see how memory behaved, to try and identify the source of the leak. I discovered two interesting things. When VR mode was disabled, there was no leak. Also when no Unity UI elements were present (in VR Mode), there was no leak. Rather the app looked like one would expect in its memory use:
It was clear something was wrong with Google VR and its VR mode specifically, in combination with Unity’s UI. This lead me to do a lot of querying online and with various people who might have had answers. However, blissfully I stumbled across a closed thread on the Google VR: as it turns out the issue is with Unity: any version greater than 5.3.1f. This version came out in February, so we had always been using an incompatible version since the start of the project! Thankfully, this meant that rolling back our project to an older version of Unity saved it.
Despite being a very stressful event, the memory leak bug gave a better understanding of Unity, Google VR, programming and memory management – especially for mobiles, which have so little memory to spare.