27 March 2013
Wednesday FAQs: Corona Bug Reports
It’s Wednesday and time for another frequently asked questions (FAQs) session. Here are some FAQs about submitting Corona Bug Reports.
1. The Corona Simulator not longer works, please fix it!
That was an actual bug report we received with no other information about the problem. We do like to know about bugs and try to fix them, but you need to supply information to help us do that. At the very minimum, we need the following items in your bug report:
- What platform are you having the problem on: Mac simulator, Windows, simulator, iOS, Android?
- If it’s failing only on a device, which ones have you tested and what version of the OS is it using?
- What Corona build are you using? If it’s a Daily Build, does it work with the Release Build? What build did it stop working on?
- Steps to reproduce the problem
- Project code to demonstrate the problem
If your project is failing when doing a build or installing on a device, try building and installing one of the Corona sample projects (e.g., HelloWorld). That will tell you if your system is set up to build and install your app.
When you’re filing a bug report, please think about what you would need to troubleshoot the problem if you were assigned this bug.
You will see the “Report A Bug” link at the top of the Corona website when you’re logged in. Please fill out the entire form and add any additional information to help reproduce your bug.
2. I posted my bug in the forums, so why do I need to submit a bug report?
A lot of bugs get posted in the Corona forums, and that’s a good thing. It makes users aware of the possible problem and others can help confirm the bug. We do monitor the forums and respond to reports, but just because we responded in the forums, doesn’t mean the bug is in our system to be fixed. You need to file a formal bug report with the information listed above. This adds it to our bug tracking system and allows us to assign a priority to the bug and route it to engineering for a fix. It also assigns a case number that can be used to track the bug.
3. My bug was rejected because I didn’t supply test code. Why?
We need test code in order to verify the bug. Just describing what you’re doing in your code is generally not enough. In many cases it’s the combination of all the code files and assets that factor into the bug. We have tried to reproduce many bug cases with only a code snippet and find that there wasn’t enough information to show the problem.
Supplying test code also helps us verify and assign your case faster. If there is a complete test project that we can run, it will be evaluated as soon as possible. Cases that require creating a new project with your code snippet, may be pushed aside until later.
4. My bug was rejected because I only supplied a main.lua file. Why?
Many cases come in with just a main.lua file attached. Sometimes this is enough to reproduce the problem but in many cases it’s not. I remember one case where only the main.lua file was supplied. I created a new project using the file and couldn’t reproduce the bug. It turned out that the bug only occurred in landscape mode. If they had supplied a complete set of project files, I would have seen the problem and saved time.
Sometimes you don’t know the exact cause of the problem so supplying an entire test project that demonstrates the issue, will help us confirm the bug and get it assigned to be fixed sooner.
5. My project is too big to submit, what can I do?
As mentioned in Question 4, we want project code that demonstrates the problem, but we don’t want your complete project. The reason is it takes to much time to go through the code and try to understand what it’s doing. Not all problems you encounter in your development will be Corona bugs so you need to debug and isolate problems you’re seeing. If in that process you find a bug, and know that it’s not something you’re doing wrong in your code, please try to create a short test case that demonstrates the problem. You can then zip up that project (with all its support files and assets) and attach it to the bug report.
We’ve had some users send us their complete project code and ask us to debug it for them. We don’t have the resources nor the time to do that and can only address bug reports where someone has taken the time to isolate and identify a Corona problem.
6 Why does the simulator crash when I run my app?
Simulator crashes occur with uncaught errors in the project code. We place a high priority on fixing errors that cause the simulators to crash, but sometimes there are errors in the project code that will crash the simulator.
If you’re running the Mac simulator, it will generate a “crash log.” Many users have sent us these crash logs after getting the crash. The crash logs give us an idea where the problem is, but don’t help us find and fix the cause of the crash.
To help solve this bug, we really need a small test project that can reproduce the simulator crash along with the steps to reproduce it.
That’s it for today’s questions. I hope you enjoyed them and even learned a few things.
Joris
Posted at 11:58h, 27 MarchWell. I stopped filing bugs ages ago, because of:
a) critical issues are not fixed
b) response time is very very slow, for paying customers
c) testcases are not always accepted.
So goodbye corona.
Danel
Posted at 18:11h, 27 MarchI have seen much of this too. I wish they would fix more bugs or reply more quickly. I work with a team and the last bug we needed fixed our manager had to pay for premium support to make them fix their own bug which I thought was really unfair.
Rob
Posted at 12:31h, 27 MarchThanks Joris, that was incredibly helpful and relevant.
So I guess we wont see you around here anymore, best of luck.
Andreas
Posted at 15:18h, 27 MarchI submitted a few bug reports with test cases.
The Corona Labs team addressed them and in a few cases even send me some info about their progress and what their plans were when it was not possible to fix the bugs in a short time.
I think it’s incredible how much work the team is doing, and without their help on some critical issues my game “Freeze!” would have taken much longer to develop.
And everybody who develops not only for iOS but for Android devices too knows that trying to get the code to run on 1900+ devices is a pain in the… flower pot … as we Germans say.
Another thing: I’m reading the forums and I’m sometimes helping out other developers who stumble about the same problems I encountered. And many times the problems were self-made and the SDK wasn’t to blame. So it is not only understandable but essential to provide a small test project – otherwise the Corona Labs team would have to debug lots of bad cases and would not have the time to work on cool, new stuff. 🙂
Best,
Andreas
Chevol
Posted at 16:18h, 27 MarchI have had similar experiences to Andreas. My bugs have all been fixed fast and I often receive emails explaining what the issue was and what they did to fix it. I can’t say enough great things about Corona and their product. They are very responsive and open to ideas and comments.
Joris I wish you luck, but I doubt you will find another company up to par with Corona and their engineers.
Andrew
Posted at 18:26h, 27 MarchI completely agree with Andreas and Chevol, and I’ve had the same positive experience submitting bug reports. The communication from the Corona team has been great, and the bugs I submitted were fixed.
To anyone reading this, the key is what Tom wrote about — you really do have to do some work yourself to isolate the bug into the simplest but complete test case you can. That’s only fair to the Corona team, who would otherwise by inundated with false bug reports. It’s actually fun detective work to figure out and isolate a bug, and doing so helps prove that it actually is a real bug (and not just a mistake in your code).
– Andrew
Stephen Lewis
Posted at 21:00h, 27 MarchI, too, have had generally positive experiences with Corona fixing bugs I submitted. At first I thought it was a pain in the butt to have to create a simple reproducible case just to submit a bug report since it’s not always easy to rip out a test case from a mature project. But there have been times when I’ve done that and discovered that the bug was my own and not Corona’s, so it’s probably a good exercise to be forced to do.
One technique I have used to create simple test cases for bugs is to start with one of the Corona supplied sample projects that is most similar to what I am doing in my own project and modify it slightly to mimic whatever is going on in my own app that I think is triggering the bug. It doesn’t take as much time as writing an entirely new project and if the bug is indeed reproducible in the test case it’s probably quicker for Coronalabs’ engineers to diagnose the problem since they are more familiar with their own sample code.
Thomas Vanden Abeele
Posted at 03:24h, 29 MarchMy personal experience was having to wait for a year until my filed bug was fixed, but actually I’m not complaining: I thought it was actually really cool that even a year after filing, someone at CoronaLabs was still methodically going over “old” bugs and trying to fix them.
After 2 years of using Corona, I’m still very very enthousiastic about the product, and the low price point. I’m an oldtimer so I clearly remember when people had to take out a second mortgage to buy a Silicon Graphics machine and pro-software 🙂
adam
Posted at 07:23h, 29 MarchIs there somewhere we can view active/reported bugs? I remember that there used to be a link to it in resources, but it isn’t there anymore.
Olivier
Posted at 09:59h, 30 MarchHi
as Andreas, I submitted à bug report recently with test cases. it was about new scrollview widget. The Corona labs team adressed it very quickly. They are doing their job perfectly.
thanks again
Olivier
Jules
Posted at 03:19h, 02 AprilIs there somewhere that we can view and browse other people’s bug reports? I would find this useful both for isolating potential bugs and to avoid submitting an unhelpful / misguided bug report.
frank
Posted at 19:06h, 13 MayI agree with the general helpfulness of the team, but strategically there are TOO many bugs.
IMHO, the dev team has to slow down and a) fix existing bugs before adding new features and b) establish a rigorous QA process including hiring a senior QA team.
And i don’t care about the price point. The developer licenses are cheap compared what you can sell an app for. What is expensive is our time we waste on debugging and reporting bugs.