Love2D freezing on shutdown

[gaming_lion]

Hello community,
I am writing my first game with love and it really is a lot of fun. It is very beginnerfriendly and I am very thankful to the makers. The people in the IRC room are also all very nice.

But I do have a problem. I already asked on IRC but we didn't get it solved. Until now, all I am doing is drawing a 2d sidescrolling tile-world (~1500x500 tiles). I generate the whole world as a 2d table and then copy this 2d array again to smaller subarrays. So I have 2 tables, each containing about 750 000 entries containing a pointer to the "material"-table.
Everything works very nicely until I end the program (I just 'x' the window). Then it normally just does nothing and at some point my OS ask me if I want to force quit love.

Does anyone have any tips on how to track down the problem?

In case someone is so nice to directly look at my code I also appended it. To recreate the behaviour, you have to start the program, scroll around a bit (w, a, s, d) s.t. the world will be fully initialized and put into the love.physics system. Then quit. I am on manjaro linux and installed love from https://www.archlinux.org/packages/comm ... 6_64/love/
(I also am very grateful for any other feedbacks about how the code looks // if anything could be handled better.)

[MMR4tzvp]

For me, it's not really frozen, but it takes a long time to quit depending on how much I scroll. If I scroll around the whole level and then quit, it takes about 40 seconds before it actually closes the window.

Maybe you could try profiling your code? I'm not sure if it would help or not. One profiler I know of is profile.lua by Ivan. There is a forum topic about it too.

[pgimeno]

It's box2d being busy freeing stuff.

Do you need all fixtures active at the same time?

[gaming_lion]

Thanks for the tips and checking that you also have a very slow down shutdown.

What do you mean by "all fixtures active at the same time"? If I take a fixture away, then I take that part of the body "out" of the physics system right? Do you mean that I probably won't need stuff where nothing happens be part of my physics system all the time? (in the same way I shouldn't render stuff that isn't on-screen?)

[pgimeno]

I mean, new fixtures seem to be created as you move, but it doesn't seem to me like they are freed as they become out of sight, hence my question. I was wondering if that was the problem.

I haven't checked your code in nearly enough detail, I just fired gdb, wandered around, and interrupted while it was busy exiting, and it invariably reported box2d freeing stuff that I assume you have allocated. This is what almost all backtraces look like (the only variation is that sometimes they happen in line 87):

Code: Select all

Program received signal SIGINT, Interrupt.
UnBufferMove (proxyId=242439, this=0x8473e88)
    at ../../src/libraries/Box2D/Collision/b2BroadPhase.cpp:89
89			if (m_moveBuffer[i] == proxyId)
(gdb) bt
#0  UnBufferMove (proxyId=242439, this=0x8473e88)
    at ../../src/libraries/Box2D/Collision/b2BroadPhase.cpp:89
#1  b2BroadPhase::DestroyProxy (this=this@entry=0x8473e88, proxyId=242439)
    at ../../src/libraries/Box2D/Collision/b2BroadPhase.cpp:51
#2  0x0806c846 in b2Fixture::DestroyProxies (this=this@entry=0xf5afe30, 
    broadPhase=broadPhase@entry=0x8473e88)
    at ../../src/libraries/Box2D/Dynamics/b2Fixture.cpp:145
#3  0x0806d471 in b2World::DestroyBody (this=0x845acb0, b=0xf4627f8)
    at ../../src/libraries/Box2D/Dynamics/b2World.cpp:180
#4  0x080db3a6 in love::physics::box2d::Body::destroy (this=0xf206ab0)
    at ../../src/modules/physics/box2d/Body.cpp:520
#5  0x080d5143 in love::physics::box2d::World::destroy (
    this=this@entry=0x8431220) at ../../src/modules/physics/box2d/World.cpp:575
#6  0x080d534c in love::physics::box2d::World::~World (this=0x8431220, 
    __in_chrg=<optimized out>) at ../../src/modules/physics/box2d/World.cpp:249
#7  0x080d54e0 in love::physics::box2d::World::~World (this=0x8431220, 
    __in_chrg=<optimized out>) at ../../src/modules/physics/box2d/World.cpp:250
#8  0x08088312 in love::w__gc (L=0xb7fbc1c0) at ../../src/common/runtime.cpp:45
#9  0xb7b295ff in ?? () from /usr/lib/i386-linux-gnu/libluajit-5.1.so.2
#10 0xb7b362f6 in ?? () from /usr/lib/i386-linux-gnu/libluajit-5.1.so.2
#11 0xb7b504cf in ?? () from /usr/lib/i386-linux-gnu/libluajit-5.1.so.2
#12 0xb7b5154f in ?? () from /usr/lib/i386-linux-gnu/libluajit-5.1.so.2
#13 0xb7b298ff in ?? () from /usr/lib/i386-linux-gnu/libluajit-5.1.so.2
#14 0xb7b6671a in lua_close () from /usr/lib/i386-linux-gnu/libluajit-5.1.so.2
#15 0x08051364 in runlove (retval=<synthetic pointer>, argv=0xbffff5b4, argc=2)
    at ../../src/love.cpp:267
#16 main (argc=2, argv=0xbffff5b4) at ../../src/love.cpp:295
(gdb) l
84	
85	void b2BroadPhase::UnBufferMove(int32 proxyId)
86	{
87		for (int32 i = 0; i < m_moveCount; ++i)
88		{
89			if (m_moveBuffer[i] == proxyId)
90			{
91				m_moveBuffer[i] = e_nullProxy;
92			}
93		}
(gdb) p m_moveCount
$1 = 136168

#4 and #5 are key here. It's destroying the physics world, and it's specifically destroying a Body.

Maybe you're attaching something repeatedly to a Body and that's what keeps it busy, I don't know. The loop over 136168 items is weird/suspicious. It takes a while to free each Body.

[gaming_lion]

Thanks so much! Especially sharing how you found out about the bug really helps me, I didn't even think of using gdb until now. Yes I was having a fixture for each of the small blocks and I was not deleting stuff that is off screen yet.

A small question maybe: Is it the right way to have a fixture for each small tile? Or should I try to create less, bigger fixtures (e.g. if I see that I have a lot of small quadratic tiles at some point, just create one big fixture for them). The latter one means more work, since I have to have an algorithm that partitions my world in as few and as big rectangles as possible and always change the different fixtures when one of the tiles gets deleted by the player. But if that is what needs to be done for performance I could do it I guess

[pgimeno]

It seems advisable, given the size of your tiles. Here's a library that might help: https://love2d.org/forums/viewtopic.php?f=5&t=83804

Edit: Actually, a better idea might be to forget about box2d and use something like bump, especially if you want the shapes that are out of sight to be collidable as well. That depends on the type of game you're after. Say if you want to be able to throw stones, and you throw one so that it lands out of the screen, you want it to stand where it landed, even if out of sight, not to disappear into the void.

[gaming_lion]

Yes I am changing my library now; I actually already did it a few days ago, I just wanted to know for the future. I now begun another game which does not use Box2D (it uses practically nothing actually) and still, as soon as I add world:generate() to my love.load(), love will afterwards take ages/freeze on shutdown. World:generate does create two 2000x2000 tables and then copies them into smaller sized tables.

I tried to use gdb as you did but it seems that the package I have is compiled without debug symbols. I wanted to compile it with debug symbols and downloaded the source, but I can't find the place where I need to modify the makefile or configure to get debug symbols. Is there a simpler alternative?

I appended my new code again

[MadByte]

Yes I am changing my library now; I actually already did it a few days ago, I just wanted to know for the future. I now begun another game which does not use Box2D (it uses practically nothing actually) and still, as soon as I add world:generate() to my love.load(), love will afterwards take ages/freeze on shutdown. World:generate does create two 2000x2000 tables and then copies them into smaller sized tables.
...

Looks like you just do way more iterations then you should.
The main problem obviously is the generate_water function. The total amount of iterations in the function: 655,360,000 (sea_iterations*(world_width*world_height*2)) + 25 iterations (mask_size*mask_size) inside each of the 655,360,000 iterations.. should result in .. 16.384.000.000 iterations.

[gaming_lion]

Haha oh yeah right. I knew it was expensive but I thought why not, I am only generating the water once. Didn't realize just how expensive it was. Thanks!