Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Code that Crashes Codea

SimeonSimeon Admin Mod
in Bugs Posts: 5,200

Hi Everyone

This is an unusual request.

The next update will focus on bug fixes and performance, so I'm asking for you to post if you know of a reliable way to crash Codea. If you can outline the steps needed to reproduce the crash in a reply to this post it would be much appreciated. I would prefer if you can reliably reproduce the issue before posting. Be as clear as possible.

For example, it could be:

  • A Lua code snippet that crashes the runtime
  • Some steps you can take in the code editor to cause a crash
  • Or steps you can take in any other part of the app

I'd like to eliminate as many crashes as possible in the next update.

If you do post a reproducible crash, please feel free to also add it to the issue tracker (link at top) so you can be informed if/when it is resolved.

Tagged:

Comments

  • dave1707dave1707 Mod
    Posts: 8,192

    @Simeon I mentioned this a while ago but I don't know if you ever tried to fix it. This crashes the editor.

    1: Create a new project.
    2: Copy some lines of code.
    3: Paste it at the last line.
    4: Crashes the editor.

  • SimeonSimeon Admin Mod
    Posts: 5,200

    Thank you @dave1707. I forgot about that one.

  • AnatolyAnatoly Mod
    edited December 2015 Posts: 884

    But @Simeon, what about mine?

    function setup()
    print("Hello World!")
    end
    function draw()
    restart()
    end
    
    1. Open the project
    2. You will see an always restarting project
    3. Close the project with the "Go To The Script" button (The first one)
    4. Crashes not the Editor, it crashes the full project
  • IgnatzIgnatz Mod
    Posts: 5,396

    @TokOut - yours is ridiculous

    Who is going to put restart in draw?

  • AnatolyAnatoly Mod
    Posts: 884

    @Ignatz, me?

  • IgnatzIgnatz Mod
    Posts: 5,396

    Sigh

  • Posts: 2,020

    This isn't a crash, but I'm having issues with 3D meshes not rendering correctly, appearing solid black at certain points. It's the same issue I reported at the end of the 2.3.2 beta thread, that appeared at build 60. Of course debugging shaders is an immensely complex process, but what makes me think it's an issue with the final version of 2.3.2 rather than with my own code, is that when I have the same code running in an Xcode project which was exported from build 58 (I think), everything renders correctly. If my Internet connection cooperates, I'll try to upload some comparison videos.

  • SimeonSimeon Admin Mod
    Posts: 5,200

    @TokOut thank you for that as well. It's an unusual situation but I'll try to fix it so it doesn't crash Codea.

  • SimeonSimeon Admin Mod
    Posts: 5,200

    @yojimbo2000 I guess a simple example is probably too difficult to come up with for that? I believe that is down to optimisations made to the renderer. I can roll those back in the next beta to see if that's the case.

  • AnatolyAnatoly Mod
    Posts: 884

    Thx @Simeon

  • AnatolyAnatoly Mod
    edited December 2015 Posts: 884

    ... I only thought about newbies, that think that restart in draw is good, and then they're code will be crashed. In lucky moments the Changings have been done.

  • Posts: 82

    A couple of days ago, one of my tabs disappeared completely, and I quickly found out it happens to all tabs cotaining special characters like á, é, ö, etc. When the project is closed and opened again, the tab will be gone.

    I saw several issues in the tracker concerning disappearing tabs, I'm not sure if what I just described is already covered.

  • AnatolyAnatoly Mod
    Posts: 884

    I tried to crash, do Zi understand right? Creating a class, using symbols like впотопнгявйадлтщ... In the code, an crash it.

  • SimeonSimeon Admin Mod
    Posts: 5,200

    @Kjell thank you for that report, it's pretty concerning. Would you be able to log it on the issue tracker? (Link at the top.)

    @TokOut I'll try using those symbols as well.

  • Posts: 82

    @Simeon Just did. Fortunately I didn't lose too much when I encountered this.

  • Posts: 2,020

    @Simeon I think I've worked out what was causing the black mesh issue in build 60+ of 2.3.2 and managed to fix it. I no longer think it's a bug, but there does seem to be a change in how shaders are attached to meshes.

    It's a bit complex, but I'll try to explain.

    Say I have a 3D scene with a bunch of procedurally generated meshes for the scenery. Each mesh is unique, ie is only drawn once, and is held in a table, scenery = {}. Each mesh is lit with a diffuse lighting shader.

    Here's the part that seems to have changed in 2.3.2. Let's say I define the shader only once, in setup (as apparently defining lots of shader objects does take up some resources. I think I read that in Apple guidelines):


    diffuseShader = { vert = [[ //blah ]], frag = [[ //blah ]] } function setup() diffuse = shader(diffuseShader.vert, diffuseShader.frag)

    then, I have lots of scenery meshes, each one has the pre-defined shader attached:

    for i =1, #scenery do
      scenery[i].mesh = mesh()
      scenery[i].mesh.shader = diffuse
    

    then, in the course of the game, I update various uniforms on the shader:

    scenery[i].mesh.shader.lightDirection = position

    or whatever.

    This sort of set up used to work. Even though the shader object is only defined once, by attaching it to lots of separate mesh objects you seemed to create separate instances of the shader, whose custom uniform variables could be set independently.

    With 2.3.2 however, if you try this, you only have one shader object. So the line:

    scenery[i].mesh.shader.lightDirection = position

    sets the lightDirection uniform not just for scenery[i].mesh, but for every single mesh that has the pre-defined diffuse shader.

    Fixing this is very very easy (but has taken me weeks to figure out!). Instead of defining a global shader object, redefine the shader object for every single instance of the mesh, like this:

    for i =1, #scenery do
      scenery[i].mesh = mesh()
      scenery[i].mesh.shader = shader(diffuseShader.vert, diffuseShader.frag)   --NEW in 2.3.2: redefine shader object
    

    This ensures you have independent shader objects capable of remembering independent uniform variables.

    This fixed the black mesh issue I was having.

    @Simeon are you able to confirm this change in how shaders are bound to mesh objects?

    This only really comes up with unique geometry that isn't being recycled across the scene. It's not an issue if you're reusing a model (eg an NPC tank or whatever), as when you're drawing the same mesh in multiple locations you'd set/reset the shader uniforms before each instance's draw command anyway.

    So it's a fairly narrow set of circumstances where people will notice a change with 2.3.2, but I thought it was worth posting about it, in case anyone else has run into this.

  • SimeonSimeon Admin Mod
    Posts: 5,200

    @yojimbo2000 thank you for the detective work! It seems to be a side effect of the more aggressive shader uniform caching in 2.3.2. The actual binding code wasn't changed, but the optimisations seem to have resulted in this shared uniform behaviour.

  • Posts: 98

    Syncing Dropbox with lots of files in the Codea folder will crash Codea.

  • AnatolyAnatoly Mod
    Posts: 884

    I found a crash, but it leaves an error alert. I connected to a project (with the including classes in the CreateClass > Connect from projects) which had the Button class in the current project and the same project. I opened the project and the code crashed.

  • Posts: 752

    @Simeon not a crash as such, but strange behaviour where assets from previous projects can be accessed from new ones.

    To recreate (iPad 3)
    1. Create new project. Add a custom sprite, "test1" to the Project assets using any externally created image
    2. Display sprite on screen

    sprite("Project:test1",WIDTH/2,HEIGHT/2)
    
    1. Run to see the sprite
    2. Exit project
    3. Create new project
    4. Use the same command to display the sprite
    5. Run the project - the sprite appears even though it is not contained in the project assets.

    After a while the new project "loses" the reference to the original sprite asset and an error is thrown.

    Not a biggie, but has caught me out a couple of times now

  • dave1707dave1707 Mod
    Posts: 8,192

    @Simeon This doesn't crash Codea, but I think this should be fixed anyways. It has to do with saveLocalData and readLocalData. The first section saves a string made of just numbers. When that string is read back in, it gets converted to a number instead of remaining a string. The second section saves a string of numbers which contains a decimal point. When that string is read back in, it remains a string. Probably because it's not all digits. The third section saves a large number and when it's read back in, it's a wrong number. Maybe because it's treated as a 32 bit number instead of a 64 bit number. The same thing happens with Project and Global Data.

    function setup()
        print("save a string of just numbers.")
        a="123456"
        print("a= "..a.."  its a "..type(a))
        saveLocalData("val",a)
        print('saveLocalData("val",a)')
        a=readLocalData("val")
        print('a=readLocalData("val")')
        print("a= "..a.."  its NOW a "..type(a))
        print"\n=========================="
    
        print("\nsave a string of numbers and a decimal point.")
    
        b="123456."
        print("b= "..b.."  its a "..type(b))
        saveLocalData("val",b)
        print('saveLocalData("val",b)')
        a=readLocalData("val")
        print('b=readLocalData("val")')
        print("b= "..b.."  its STILL a "..type(b))
        print"\n=========================="
        print("\nsave a large number.")
    
        a=987654321
        print("a= "..a.."  its a "..type(a))
        saveLocalData("val",a)
        a=readLocalData("val")
        print("a= "..a.."  its a WRONG "..type(a))
    end
    
  • edited January 2016 Posts: 123

    I have found out a crash. If I put pRect.destroy() (pRect is my physics.body), at a convenient place, (not draw, for example) I run the app, and it crashes. I was pretty puzzled. I may be a bug. You should check that.

  • Posts: 2,020

    It should be with a colon, myBody:destroy()

  • Oh

  • edited January 2016 Posts: 103

    I found one! Normally when you're running code, you can swipe from the left side of the screen to open the code editor. If you set supportedOrientations(PORTRAIT) and hold your iPad in landscape mode, then swipe from the side of the screen (I guess from the bottom) it messes up the orientation

  • I know a very annoying bug, but not a crash.

    Whenever I am coding, I code, run the code, and there is like a 4/10 chance of the keyboard popping up when you open the editor after running the program. (Even if I closed the keyboard before runnIng the code), and whenever I type in the editor, it glitches MAJOR. It puts random symbols everywhere. You can't get rid of the keyboard unless you exit out of Codea. It's a bug, for sure

  • edited January 2016 Posts: 72

    @Simeon

    I don't know of a crash. But my tabs are getting deleted sometimes randomly. It's the far most right ones too. (I have a lot).

    I launched my app then went to edit some code and launched again and two of the tabs to the far right were deleted. This happened once before. It doesn't reoccur a lot.

    This has happened twice and I will keep an eye out for it.

    I didn't' have an special characters.

  • AnatolyAnatoly Mod
    Posts: 884

    Another not a crash but if you use fill emojis get filled, if you want that the emoji won't be filled noFill will remove colors moment an. How then to get emoji?

  • I don't know if it's a bug, or...

    Anyway, if I put:

    if Sent and Message == "Destroy" then
    Ball:destroy
    End
    End

    If I do that, I run it, AND IT ALWAYS HAS A ERROR.

  • IgnatzIgnatz Mod
    Posts: 5,396

    Hey, guys, this thread is about CRASHING Codea, not causing bugs

  • Yea, but how do you resolve my question?

  • SimeonSimeon Admin Mod
    Posts: 5,200

    Thank you for all the reported issues. I'll be using this thread as reference while I fix bugs.

  • IgnatzIgnatz Mod
    Posts: 5,396

    @LL_Phoenix456 - put brackets on the end of destroy

  • I did, it does the same thing, error. :(

  • IgnatzIgnatz Mod
    edited January 2016 Posts: 5,396

    @LL_Phoenix456 - post some more code, but not in this thread (it is very likely you have coded something wrong, and it is unlikely to be a problem with Codea, so this is the wrong place to put it).

  • Ok, I will make a new thread

  • AnatolyAnatoly Mod
    Posts: 884

    @simeon, does it mean the post will be stickied? (On top)

Sign In or Register to comment.