Code that Crashes Codea

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.

@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.

Thank you @dave1707. I forgot about that one.

But @Simeon, what about mine?

function setup()
print("Hello World!")
function draw()
  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

@TokOut - yours is ridiculous

Who is going to put restart in draw?

@Ignatz, me?


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.

@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.

@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.

Thx @Simeon

… 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.

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.

I tried to crash, do Zi understand right? Creating a class, using symbols like ???.. In the code, an crash it.

@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.

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

@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.

@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.

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

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.