Problem with daily build 1031

#21

I’d support that “make it configurable”-option. I tried to update from 971 to 1035 and hit this one. I have a pretty long lasting “known unknown” bug in scene change that regularly causes a “reference with nil index”-error. The scene change logic is a bit on the complex side, i.e. to optimize load times the next scene computation is done in parallel while the previous scene is transitioning out. So hundreds of graphical objects going in and out with transitions. Depending on the timing and scene structure the bug occurs sometimes but not always.

It’s a bug I’ve used many of days to track. But it causes absolutely no visible problems, probably with the last decommissioned graphical objects out side of screen. It’s once-per-game, and if there would be memory loss it’s not visible. So I’ve just learned to live with. And would not like to “stop everything until I find this”. [import]uid: 46570 topic_id: 36163 reply_id: 144008[/import]

#22

We did the mistake to released the update to the customers but we had a strong reasson: Remove the corona unnecesary permission (google contacted us asking about this permission before making our app featured on google play).

We can not drop back to previous version (before 1030) as all the permission would be required again to the users before updating the app.

The main problem for us is that the update 1030 finally removed the unnecesare permission . Now the permissons have been removed but brings big problems due to some occasional and not necesary runtimes errors in very few devices, getting force close, thing that have never happened before. A solution whould be to show the errors only when the apk is signed with debug key.

Keep us informed.

[import]uid: 88967 topic_id: 36163 reply_id: 144032[/import]

#23

Is there any chance that this could be changed? We would hardly need to remove the Android permissions but because of this change, Corona 1030 and higher is unusable for us. Its a very bad idea to crash the app when it is not necessary… [import]uid: 7038 topic_id: 36163 reply_id: 144434[/import]

#24

@Bohumil Vosicky I think most advice to programmers is to not release bugs into the wild. Corona did a good job of hiding a lot of bugs from you because it didn’t abort and they could easily sneak into your code. I can’t count the times I tought things were fine, but while monitoring my logs for other messages I see all the Lua pcall errors flying by. My app was not working as expected. Perhaps it wasn’t saving data or passing the users’ turn information along or what ever. Since the program kept running I would go on my merry way, none the wiser. Now with this, through normal testing you should catch these and fix them. I understand that on the Android side, there are enough edge cases of weird hardware/software combinations that it’s not perfect.

The engineers are taking your feedback and figuring out the best practice going forward.
[import]uid: 199310 topic_id: 36163 reply_id: 144472[/import]

#25

“…on the Android side, there are enough edge cases of weird hardware/software combinations that it’s not perfect…”
Yes, exactly. This is the problem. Especially with some hardware. If we built just for Nexus 7, it would be no problem at all. But our customers use various Chinese craps bought in Walmart and want to use them with our apps…

I red the Wednesday FAQs: Corona Run-Time Errors. The idea with “run-time listener that will trap errors” sounds great. It would solve this issue and help us a lot. But as every software developer I am really afraid of “should be available soon” phrase :slight_smile:
[import]uid: 7038 topic_id: 36163 reply_id: 144477[/import]

#26

This is likely an error you were already having. Bear with me.

When we removed the permissions, to help people spot errors, we turned on a feature that shows runtime errors in a box like that. I suspect you were having this error already, but the way Corona errors have worked in the past, only the chunk the error happened in, and many times your app can continue without issue.

It sounds like it’s now exiting on these errors. I’ll ask the team about that behavior. This happened in build 1030 and here is the relevant release notes:

Android: Improved error handling. Now displays specific Lua runtime errors onscreen and outputs Lua stack trace to Android log. Outputs Lua file name and line number for debug builds. Also displays Java exceptions invoked by Lua onscreen, such as missing permissions.

Now to find the error. There are several API’s that have a pause() method including:

audio
physics
timer
spriteObject and
video

You are probably trying to access an object that is created with one of these that has been overwritten or removed/nilled out. [import]uid: 199310 topic_id: 36163 reply_id: 143657[/import]

#27

The same problems like hazex. Some of our apps which never crashed now display this error on the display and then are force closed. They are 2 years or more old apps so I am absolutely sure that they never crashed at these situations.
Yes, I believe it’s an error in our app and it can be fixed. OK. But it’s very difficult to reproduce and they are quite rare. I would prefer if Corona worked like before. We have about 40 apps and probably this can affect each of them… [import]uid: 7038 topic_id: 36163 reply_id: 143793[/import]

#28

I’ve checked with the team and yes, it is intentional to exit after a runtime error. Previously, if we let the code continue, your error might go unnoticed and be doing bad things behind the scenes. It’s considered a good thing to not release bugs into the wild, but on the Android side, there are so many device/OS/carrier combos that it is impossible to test every device. I’ll share this back and let the engineers think about it.

[import]uid: 199310 topic_id: 36163 reply_id: 143815[/import]

#29

Hello,

Thanks for the fast answer.

Finally we managed to reproduce the issue, it is difficult to reproduce. I have obtained some extra info when compiling using debug key.

Wouldn´t be a good idea to show only the error when using debug key in the compilations?
Showing error messages to the users is not good, specially if before this they could continue with the gameplay and now they have a error message and then a force close.

We are aware now that there is an error in our code that affects few devices ocasionally but we would like to make sure that this force close does not appear due to the new error message.

Regards

[import]uid: 88967 topic_id: 36163 reply_id: 143789[/import]

#30

Thank you Rob. I understand your arguments and I really appreciate sharing this with the engineers…
Just one example: We tested an old app today built with the new daily build. It randomly crashes once in 20-30 minutes. With an old build, you could work with it for hours and nothing happened. All customers were happy for many months or years. The app was sold well with almost no technical support questions. You know - when something works, don’t fix it…
Reproducind and fixing such error may take days. For 40 apps it can take months… The possibility to switch this error messages off would save us months of work.
And I worry that some of these errors cannot be fixed. They happen only sometimes, for example on slow devices (like Nook 1st gen) when it can have too many reasons. [import]uid: 7038 topic_id: 36163 reply_id: 143826[/import]

#31

@Bohumil Vosicky, I guess I’m a little confused. First, the changes we made would only affect new releases. So just to make sure I understand, you released a new version to your customers.

Also, Daily Builds are cutting edge and are known to change how things behave. If this is creating a problem, just drop back to 1030 or a previous build and release with that until you can test with 1031 or later and track down the bugs. These changes should help you find bugs better.

We would like to hear more thoughts on this. [import]uid: 199310 topic_id: 36163 reply_id: 143830[/import]

#32

I am sorry, I’ll try to be more clear. Of course, this is a problem with the new build only and happens only to our testers. I did not release any apps made with this new build to customers.
Of course, it’s OK with older builds.
But I am little bit scared that this change will be permanent and this can be a lot of work for us in future.
Thank you for helping me with this issue. [import]uid: 7038 topic_id: 36163 reply_id: 143858[/import]

#33

I’d support that “make it configurable”-option. I tried to update from 971 to 1035 and hit this one. I have a pretty long lasting “known unknown” bug in scene change that regularly causes a “reference with nil index”-error. The scene change logic is a bit on the complex side, i.e. to optimize load times the next scene computation is done in parallel while the previous scene is transitioning out. So hundreds of graphical objects going in and out with transitions. Depending on the timing and scene structure the bug occurs sometimes but not always.

It’s a bug I’ve used many of days to track. But it causes absolutely no visible problems, probably with the last decommissioned graphical objects out side of screen. It’s once-per-game, and if there would be memory loss it’s not visible. So I’ve just learned to live with. And would not like to “stop everything until I find this”. [import]uid: 46570 topic_id: 36163 reply_id: 144008[/import]

#34

We did the mistake to released the update to the customers but we had a strong reasson: Remove the corona unnecesary permission (google contacted us asking about this permission before making our app featured on google play).

We can not drop back to previous version (before 1030) as all the permission would be required again to the users before updating the app.

The main problem for us is that the update 1030 finally removed the unnecesare permission . Now the permissons have been removed but brings big problems due to some occasional and not necesary runtimes errors in very few devices, getting force close, thing that have never happened before. A solution whould be to show the errors only when the apk is signed with debug key.

Keep us informed.

[import]uid: 88967 topic_id: 36163 reply_id: 144032[/import]

#35

Is there any chance that this could be changed? We would hardly need to remove the Android permissions but because of this change, Corona 1030 and higher is unusable for us. Its a very bad idea to crash the app when it is not necessary… [import]uid: 7038 topic_id: 36163 reply_id: 144434[/import]

#36

@Bohumil Vosicky I think most advice to programmers is to not release bugs into the wild. Corona did a good job of hiding a lot of bugs from you because it didn’t abort and they could easily sneak into your code. I can’t count the times I tought things were fine, but while monitoring my logs for other messages I see all the Lua pcall errors flying by. My app was not working as expected. Perhaps it wasn’t saving data or passing the users’ turn information along or what ever. Since the program kept running I would go on my merry way, none the wiser. Now with this, through normal testing you should catch these and fix them. I understand that on the Android side, there are enough edge cases of weird hardware/software combinations that it’s not perfect.

The engineers are taking your feedback and figuring out the best practice going forward.
[import]uid: 199310 topic_id: 36163 reply_id: 144472[/import]

#37

“…on the Android side, there are enough edge cases of weird hardware/software combinations that it’s not perfect…”
Yes, exactly. This is the problem. Especially with some hardware. If we built just for Nexus 7, it would be no problem at all. But our customers use various Chinese craps bought in Walmart and want to use them with our apps…

I red the Wednesday FAQs: Corona Run-Time Errors. The idea with “run-time listener that will trap errors” sounds great. It would solve this issue and help us a lot. But as every software developer I am really afraid of “should be available soon” phrase :slight_smile:
[import]uid: 7038 topic_id: 36163 reply_id: 144477[/import]

#38

This is likely an error you were already having. Bear with me.

When we removed the permissions, to help people spot errors, we turned on a feature that shows runtime errors in a box like that. I suspect you were having this error already, but the way Corona errors have worked in the past, only the chunk the error happened in, and many times your app can continue without issue.

It sounds like it’s now exiting on these errors. I’ll ask the team about that behavior. This happened in build 1030 and here is the relevant release notes:

Android: Improved error handling. Now displays specific Lua runtime errors onscreen and outputs Lua stack trace to Android log. Outputs Lua file name and line number for debug builds. Also displays Java exceptions invoked by Lua onscreen, such as missing permissions.

Now to find the error. There are several API’s that have a pause() method including:

audio
physics
timer
spriteObject and
video

You are probably trying to access an object that is created with one of these that has been overwritten or removed/nilled out. [import]uid: 199310 topic_id: 36163 reply_id: 143657[/import]

#39

The same problems like hazex. Some of our apps which never crashed now display this error on the display and then are force closed. They are 2 years or more old apps so I am absolutely sure that they never crashed at these situations.
Yes, I believe it’s an error in our app and it can be fixed. OK. But it’s very difficult to reproduce and they are quite rare. I would prefer if Corona worked like before. We have about 40 apps and probably this can affect each of them… [import]uid: 7038 topic_id: 36163 reply_id: 143793[/import]

#40

I’ve checked with the team and yes, it is intentional to exit after a runtime error. Previously, if we let the code continue, your error might go unnoticed and be doing bad things behind the scenes. It’s considered a good thing to not release bugs into the wild, but on the Android side, there are so many device/OS/carrier combos that it is impossible to test every device. I’ll share this back and let the engineers think about it.

[import]uid: 199310 topic_id: 36163 reply_id: 143815[/import]