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

I don’t think this bug has anything to do with Director (please take a look at previous posts in this thread, nobody was saying anything about Director, why you want to take Director into account?)

I was using Storyboard when I first saw this bug happening by the way. I have migrated to Composer but I have not tested this bug again because I am not Corona QA.

In an earlier post, someone was saying this bug might be related to scrollView (which is removed right away). Do you have any scrollView in your app? And do you have the case that might remove a scrollView right after it’s created?

Someone was saying this bug might be related to scrollView (which is removed right away). Do you have any scrollView in your app? And do you have the case that might remove a scrollView right after it’s created?

Yes, I do have a scrollView. 
But I am not removing it "right after it’s created"

That said, this bug happens right after I remove the scrollView(which is done when I am changing scenes).
But since the error generates no useful stack data, I am unable to pinpoint the error any further
 

Try to play around with the removal of the scrollView, for example:

  • totally remove scrollView to see if this bug happens (if it’s still happening, it must be something else other than scrollView)

  • change the places to remove it (earlier or later)

  • set a timer for 1ms to remove the scrollView

To see if you are lucky to find the work around. (as long as it’s really scrollView removal that causes this problem… but no one has truly identified it yet).

I have tried a lot… and still trying.

The problem is I haven’t been able to reproduce the bug by myself even once.
I detected this bug from a published version of the app (via Gameanalytics and Flurry).

Anyway, thanks for the help.
Hopefully I will be able to find the bug. 

Even though it might not be the Director class that’s causing this particular problem, my main point was that I don’t think it’s wise to develop *new* apps using a 3rd party module that isn’t actively supported anymore. 

It’s bound to break at some point, and the more apps anybody has that use it, the more work it will be to migrate. Unless debugging and fixing the Director class is something that sounds like fun…  :wink:

There might be some “quick” user operation that causes it. 

So you might want to try clicking on something really quick or go to other scenes really quick by using your finger.

For me, if I swipe the screen really quick, I saw this bug in my app.

Good luck!

@ingemar  Fair enough.  This project is an old one(2 years old), and I don’t really have the patience(or the time) to port it as long as it works. The moment some Corona version completely breaks director, I guess that will be the time I will be feeling sorry I didn’t heed your advice :smiley:

@joe Thanks for the pointers. Hope to find this bug soon.

On a side note, would really love some inputs from Corona staff.
They should atleast know what generally causes this bug.
Guys? 

@Satheesh

I can appreciate that migrating an older project isn’t a priority as long as it works. I have a few projects that still use Graphics 1 syntax which will be in need of an update soon.  :lol:

@Satheesh

When you post a question in the forum, usually Rob (Corona staff) will come up and say something (Just like this thread for example and no one else in Corona staff will respond unless they really like your bug for some reason). If Rob can’t help you or other forum members can’t help you, usually it means you have to either figure it out by yourself or provide more “accurate” evidence (usually meaning to reproduce it and file a bug report).

I think Corona has no “QA resources” to dig out these problems for you, even for themselves proactively. You are the one who is responsible to dig it out if you really care about it a lot unless they think some bug is too vital to be ignored.

And even if you can reproduce a bug & file it, you never know when it will be fixed. It can be fixed in couple of weeks or sit there for years.

Regarding Director.  Almost everyone who’s tried to use Director with a G2.0 app has run into problems.  They have to run in graphicsCompatibility = 1 mode to work.  Director has never been updated to use the new Graphics 2.0 placement and anchors.  For those building with Director today they are doing it in Compatibility mode.   That said, there is likely a scrollView bug that may be related to the old positioning. 

But unless we know what specific behavior you are doing to trigger this, it’s really hard for us to track it down.  Our widgets pass our use cases.  But you all tend to find other ways to use it.  This is why bug reports with a functioning project that has the issue is imperative as you have a way to demonstrate the issue.  If not, we have to try and guess what it is you’re doing.

Satheesh, the forums say you are a starter, but you appear to be using a daily build.  Are you a pro subscriber?  If so, why not get the latest daily build and give it a go (2306 I think).  There have been a bunch of widget fixes including a bunch of scrollView specific errors.  Also it would be helpful for you to show the error message here.  There are at least 2-3 different errors posted in this thread, I’m not sure exactly which one you are getting.

Rob

@Rob As a matter of fact, I am using Graphics 1.0 Compatibility version. 

As I mentioned before, the problem is even I can’t reproduce the bug in my app… I am trying all sorts of nonsensical input data, but to no avail.

I will try with the latest build(haven’t got much hope though, seeing how this error has been here for long). And BTW, this is my personal account, and our company account is a PRO one. 

1 quick question : 
The stack traceback mentions lines numbers 141 and 218 - the same as for Joe. Nothing else. Do you know what these line numbers mean? If they are line numbers from some file in the widget library, they it might be worth it to mess around with the widget library source code. 

They are likely from the widget library or more specifically a widget in the widget library.  What widgets are you using?

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!