Game freezes randomly

[Ayte]

Hi,

I've been working on a platformer for the past month. ( if you want to try it, you can move with the arrow keys, jump with the "z" key, and groundpound with "x" )

However, sometimes, the game simply freezes. The game window doesn't refresh, and I can't "CTRL-C" in the terminal to kill the game, I'm forced to use "killall -9 love" in order to terminate it ( I'm on Linux ). It seems to happen randomly, in no specific place.

Here's a list of things I already tried to pinpoint the problem :
- I tried my game on another computer / another operating system, and the freeze still occurs, so it's not just my computer
- I noticed that such freezes can occur if an infinite while loop is present, however I just have 4 while loops in my codebase, and none of them are infinite.
- I tried disabling my shaders, and the freeze still occurs
- With the help of print statements, I noticed that the freeze has only occured inside the love.update function, and only during the "step" function of the following objects : the player, the cars ( moving platforms that are inside the first level ), the transitions ( the screen fading between two levels ), and the falling platforms ( that are present in the third level ).


Does anybody have an idea why this kind of freeze is happening ? Or is there a better way for debugging my game than putting a bunch of print statements ? I'm kinda lost here


Thanks in advance,
Cheers

[knorke]

The first step is to reproduce the crash.
So if you think it might have to do with the moving platforms then make a testlevel with many of those objects.

I played for a few minutes and it did not freeze.
However, there was a trampolin with a sign that read "Use groundpound to jump higher!"
I did not know the button to groundpound but somehow was still able to reach the next platform. (by hitting the side of the right wall and glitching (?) upwards)

Recently there was this thread:
viewtopic.php?p=247708#p247708 about box2D physics freezing up when too many collisions happen at once. Maybe something similiar?

[BrotSagtMist]

not able to reproduce it, finished all 3 levels.
If you dont find the actual trigger this is going to be hard.

[Ayte]

The first step is to reproduce the crash.
So if you think it might have to do with the moving platforms then make a testlevel with many of those objects.

I played for a few minutes and it did not freeze.
However, there was a trampolin with a sign that read "Use groundpound to jump higher!"
I did not know the button to groundpound but somehow was still able to reach the next platform. (by hitting the side of the right wall and glitching (?) upwards)

Recently there was this thread:
viewtopic.php?p=247708#p247708 about box2D physics freezing up when too many collisions happen at once. Maybe something similiar?

Thanks for your response.
I'm actually not using Box2D for my collisions, but thanks for the link.
I also experienced the freeze when there was no moving platform at all, it happened multiple times, but I can't seem to figure out what triggers it.

( regarding the spring, you can use "x" in the air to perform a groundpound, and you probably wall-jumped off the wall )

[pgimeno]

I hit the jackpot on my first try, I started a game and at the end of the first level, with the screen black, the game froze (the transition you mention, I guess).

Out of curiosity I attached gdb to the still running process (gdb --pid <pid>). To my surprise it printed some useful information. The backtrace was useless, of course, but then I started stepping instructions (gdb command SI) and it printed the names of several functions it was executing. Here's the functions that got executed:

Code: Select all

lj_BC_GGET
lj_BC_TGETS
lj_BC_CALL
lj_ff_ipairs
lj_fff_res
lj_fff_res_
lj_BC_JMP
lj_BC_ITERC
lj_ff_ipairs_aux
lj_fff_res2
lj_fff_res 
lj_fff_res_
lj_BC_JITERL
lj_BC_JLOOP
??
lj_vm_next
??
lj_vm_next
??
lj_vm_next
??
lj_vm_exit_interp
lj_BC_ITERC
lj_ff_ipairs_aux
lj_fff_res2
lj_fff_res0
lj_fff_res
lj_BC_JITERL
lj_BC_ITERC
lj_ff_next
lj_tab_next
lj_tab_keyindex
hashkey.isra
lj_tab_keyindex
lj_obj_equal
lj_tab_keyindex
lj_obj_equal
lj_tab_keyindex
lj_obj_equal
lj_tab_keyindex
lj_tab_next
lj_ff_next
lj_fff_res2
lj_fff_res
lj_fff_res_
lj_BC_IITERL
lj_BC_ISEQP
lj_BC_GGET
lj_BC_TGETS

The lj_BC_xxx mostly seem to correspond to the interpreter opcodes. At some point it enters lj_BC_JITERL followed by lj_BC_JLOOP, and after that it executes unnamed code. I believe that's JIT-compiled code. Later it executes lj_exit_interp that I take as leaving compiled mode and returning to interpreter mode. There are some functions with names like lj_ff_*, lj_fff_* and lj_tab_* which I take as internal functions. Most relevantly, it's executing an ipairs().

I think I gave up too early tracing; unfortunately, I only got two freezes (consecutive!) then I didn't get a freeze anymore and I couldn't trace further.

With more function names, it might become possible to identify what section of the code is executing and why it's freezing. I ran it about 20-30 more times but I didn't get any other freezes.

After that first debugging session, my first suspicion was that it was executing function findName(), so I added a print() statement to it but I didn't get a freeze at the start of the function. I added a print inside the outer loop, but I got no further freezes and I couldn't test anymore. Also, the function looks quite straightforward, and it doesn't look like it has any reason to freeze. It's still possible that the loop is on a caller, though.

If you can reproduce it again, try stepping with gdb and taking note of the names of the functions it executes, and post them here as I did.

It's also a good idea to print backtraces on suspects: print(debug.traceback()). If you manage to place one at the point where it gets stuck, you can see where the infinite loop is happening and where it is called from.

Side note, instead of kill -9, you can interrupt by sending SIGQUIT instead of SIGINT, with Ctrl+\ or Ctrl+4 or both, depending on your keyboard.

Edit: For a bug that was similarly tough to reproduce, I used the method that I outline here: viewtopic.php?p=229957#p229957 - basically, make the delta time fixed (I used 0.015625 which is 1/64, that's an exact floating point number so there are no rounding errors); count frames, record all keypresses/keyreleases and the frame when they happen, and once you get a crash, replay them, each at its corresponding frame count.

[ReFreezed]

I got the freeze a few times in different parts of the game, but after waiting long enough one time an error was raised!

Code: Select all

Error
table overflow
Traceback
[love "callbacks.lua"]:228: in function 'handler'
[C]: in function 'insert'
game.lua:182: in function 'findName'
objects/movable.lua:18: in function 'inWater'
objects/player.lua:173: in function 'state'
objects/player.lua:368: in function 'step'
game.lua:208: in function 'step'
main.lua:41: in function 'update'
[love "callbacks.lua"]:162: in function <[love "callbacks.lua"]:144>
[C]: in function 'xpcall'

Same error with a similar but different traceback:

Code: Select all

Error
table overflow
Traceback
[love "callbacks.lua"]:228: in function 'handler'
[C]: in function 'insert'
game.lua:182: in function 'findName'
objects/movable.lua:8: in function 'new'
objects/enemies/enemy.lua:5: in function 'new'
objects/enemies/bug.lua:10: in function 'new'
objects/tileset.lua:34: in function 'new'
scenes.lua:6: in function <scenes.lua:3>
objects/transition.lua:33: in function 'step'
game.lua:208: in function 'step'
main.lua:41: in function 'update'
[love "callbacks.lua"]:162: in function <[love "callbacks.lua"]:144>
[C]: in function 'xpcall'

I monitored the memory usage for the program and noticed it jumping up in very large chunks a few times before the error, I assume until all my memory was consumed and a memory allocation error got triggered because of it. Look at what things you loop through in Game:findName() to help find the problem.

Another completely unrelated thing I noticed - you got a lot of code like this:

Code: Select all

for i,v in pairs(tbl) do
	if v~=nil then

'v' will never actually be nil in pairs/ipairs loops, so the if statement is useless in all these places.

Edit: Added another error traceback.

[pgimeno]

Something I suspected was that it's a pairs() or ipairs() loop inserting an element in the same table it's iterating (for pairs(), that's undefined behaviour in Lua; for ipairs() it would just loop endlessly). That aligns with what you have observed. That is, something similar to this example:

Code: Select all

local t = {1}
for i, v in ipairs(t) do
  table.insert(t, 1)
end

I reproduced it once more and was able to narrow it to this point in tileset.lua, which isn't narrow enough yet:

Code: Select all

                                        game.objects[v.name]:new(game,obj)

Unfortunately I didn't print v.name, and I could not reproduce it again, so I don't know which object it was trying to create that causes the infinite loop.

[pgimeno]

I'm now convinced that it's a LuaJIT bug rather than a game bug. The freeze is definitively in findName (in my case the call to game:findName("Tileset") in breakable.lua), and it doesn't have any reason to freeze there.

A workaround could be, after defining Game:findName(), to add:

Code: Select all

jit.off(Game.findName)

[Ayte]

I'm now convinced that it's a LuaJIT bug rather than a game bug. The freeze is definitively in findName (in my case the call to game:findName("Tileset") in breakable.lua), and it doesn't have any reason to freeze there.

A workaround could be, after defining Game:findName(), to add:

Code: Select all

jit.off(Game.findName)

Thanks for helping me with this, this solution seems to work

[milon]

I'm now convinced that it's a LuaJIT bug rather than a game bug...

Any idea what the actual bug is, or how the rest of us can avoid it? I couldn't follow most of the jit-related stuff and just want to know what to avoid in my code, or when I need to potentially turn jit off.