Is this a crash in Corona? (Please see this console log)

In this particular scene where the error occus,

Buttons

1 Spinner 
1 Scrollview

The scrollview itself contains a number of widget buttons…
Buttons(and some texts) are inserted dynamically into the scrollview. 

Initially I thought that inserting items into the scrollview after the scene was cleaned was the problem and I placed various checks to prevent that. 
Apparently that’s not the cause of the problem.

Ok Good news! 

I updated the Corona to the latest build, and Presto! I was able to reproduce the bug in the simulator. 
I got the same error… 

Now I downloaded the widget library from Github, and used that widget instead hoping to get more insights on the error… 
This is the error which I got : 

 

/Users/Timeplusq/Desktop/pord/Doodle2/widgetLibraryCustom/widget\_scrollview.lua:389: attempt to compare number with nil stack traceback: /Users/Timeplusq/Desktop/pord/Doodle2/widgetLibraryCustom/widget\_scrollview.lua:389: in function '\_listener' ?: in function \<?:141\> ?: in function \<?:218\>

In the widget_scrollView.lua, in line 384 in the scrollView:insert function, there is a function which is called with a timer delay of 2.
Even after the scrollview is removed this function is called, which is the reason for the error… 

 

So apparently, this error occurs when the scrollView is removed in the very same frame something is inserted into the scrollView

And we can even replicate this(thankfully)
 

local scrollview = widget.newScrollView() scrollview:insert(display.newRect(0,0,100,100)) scrollview:removeSelf()

That throws an error! 

Good job, Satheesh

Your reward is …

Compose a sample project that reproduces this error and file a bug report with it.

Yep. Doing that right now.

Filed Bug Report : Case 32941
Hope this gets fixed soon.

 

Good job, Satheesh

Your reward is …

Compose a sample project that reproduces this error and file a bug report with it.

@Joe Lol!  
I did not read the full post properly before.  
Missed the second line, and hence the sarcasm :slight_smile:

Thanks for filing the bug report. 

So apparently fixing this bug is not worth the time.  According to the support team : 
 why would you remove scrollview right after you inserted something into the view. Seems like an edge case that shouldn’t happen and can be programmed around.
 

Disappointing!

:blink: I agree that’s disappointing.

The test project is just to show *how* you can force it to happen! That’s what they want. A repeatable test case.

In a real-world app you don’t intentionally do it like that, but users can always find a way to make strange things happen by performing the right combination of taps. It can also be as simple as having events that fire in a certain order that forces this to happen, and developers have no control of in which order events are triggered.

Edge case or not, it *is* a bug. Even though the priority might not be high, it shouldn’t just be shrugged off.

Exactly. 
I even replied back to them, describing how the the bug affected my app specifically,  pointing out that it was not at all an edge case(a rare case, one can say though).

They did not reply to that mail, nor to a further 2 of my mails :frowning:
Haven’t got much hope. 

The bug has been reopened.  However, here in the US this is a 3-day holiday weekend, so it may take a few days before we can take another look at it. 

Rob

why would you remove scrollview right after you inserted something into the view. Seems like an edge case that shouldn't happen and can be programmed around.

I totally disagree with such a reply.

This case can happen because you cannot expect how UI is implemented & how a user interacts with it.

I originally reported this problem because it happened in my UI case. For example, I create a screen with scrollView & a touch event to remove this screen. How could you expect “when” a user touch the screen and trigger it? What if the user clicks on something on the screen to remove the screen right after it’s created. 

More than one developer had posted on this thread saying they are seeing the same error. How could we all intentionally do such a non-sense thing?

The test case from Satheesh is just to reproduce the error in a straight forward way. He made a great effort to discover the mystery, what a great job. But Corona’s reply really makes people feel disappointed!

Satheesh,

#3, lol

programmer.jpg

I’ve got this problem too, are there any plans to fix the bug?

thanks

Let me check with the engineers on it.  We are getting ready to resume daily builds and I know additional widget bugs are being addressed.

Rob

Just ran into this myself… Curious about the progress on a fix.

By the way, in my case, I have a list down the side where the user can pick stuff, and depending on what they pick, it updates the scrollview object that takes up the rest of the screen.  Imagine chapters in a book, for example.  If I click one really quick, I get this exact error, and I’ve been scratching my head for about two hours trying to figure it out…

The engineer has fixed this, it’s a matter of passing QA and making it into a daily build.  Look for the next batch of widget fixes.

Rob

That’s great! Thanks!

I’ve got this problem too, are there any plans to fix the bug?

thanks