LÖVE

Hey all! I've started working on a game (I'm about 7 weeks into development) with love2D and I've been enjoying it.

I've been working on clearing the game of bugs and I've run into a bit of an issue. While messing around with a play tester, I got the error "A fixture has escaped Memoizer!" I've tried using google, but I'm not really sure what would cause this issue and what would be a good fix for it. Rather than bang my head on a wall repeatedly, I've decided to come here.

I just want to know what the error means, and some common causes / gotchas that can cause the issue so that I can work on debugging. The source code for the game is fairly large (28 GB, but a fair ammount of that is sound) and the error is fairly rare so I'm not planning on posting it here. However, if it is helpful for the community then I can potentially consider posting the .love to the site.

Some general notes about stuff I'm doing with the physics engine (I'm not sure if any/all of these points are relevant, so feel free to ask additional questions):
1. I am using world:destroy() to unload the physics world, then when reloading the world I create a brand new physics world and try to replicate the fixtures (basically I'm trying to simulate launching the script again without relaunching the entire game / multiple scripts again).
2. I do set the callbacks for the physics world.
3. I am 90% confident that I'm destroying all of my unused physics objects, however I do not call their :release() methods. (In fact, I don't call the :release() methods on that many of my objects, and just let the garbage collector deal with anything I'm missing.)
4. The error occurred about 3-4 seconds after loading a new physics world after having previously created and destroyed 1-2 physics worlds.
5. Since the error was a bit unexpected, I'm not 100% sure if there were any overlapping physics objects at the time of crashing. It is possible that there were objects that were in contact with each other.
6. The game does create a fairly large number of physics objects. (We'll say about 50-75 depending on what's going on during a specific frame).
7. This happened in love2D version 11.1 on a windows 7 machine. (I'm seriously considering updating to love2D version 11.2 in the near future, though)
8. The physics engine updates at a set tick rate (100 ticks per second).
9. This has only happened once in the course of days of on and off playtesting.
(Edit) 10. The error pointed to the world:update() function.
(Edit #2) 11. I do not call lua's collectgarbage function at any point (but I may need to )
(Edit #3) 12. The error, as far as I can tell, cannot be recreated by just messing around in my game, although I haven't tried creating a new project specifically to create the error.

I will try to watch this thread for any new posts, so let me know if there is any additional information that you need.

This is a LuaJIT optimization-related error; there's a table called "memorizer" that stores all physics objects, and the error text means exactly what it says.

Physics module implementation is a little bit buggy. Try manually deleting every single physics object before deleting the world. In fact, at that point you don't need to delete the world, you can reuse the instantiated one.

Thanks for the reply!

Deleting all of the physics objects in a world seems like a bit of a pain. Would it be possible to write my own function that does the same thing as world:destroy() using, for example, the world's getBodies(), getContacts() and getJoints() functions? Or do I need to keep track of all of these lists myself?

_DaCoolOne_ wrote: ↑Tue Aug 06, 2019 5:59 pm Deleting all of the physics objects in a world seems like a bit of a pain. Would it be possible to write my own function that does the same thing as world:destroy() using, for example, the world's getBodies(), getContacts() and getJoints() functions? Or do I need to keep track of all of these lists myself?

I'd assume you already have a full list(s) of all of these, because otherwise the bodies get garbage collected? Just iterate over them in a loop and call :delete on them. Don't be lazy with coding, that's the #1 source of weird hard to trace bugs.

Okay, I'll see what I can do.

You can get away without calling destroy() on each body.
I believe this bug can be avoided if you make sure that ALL of your references are set to nil and collected BEFORE calling world:destroy()

If that's the case, that would be significantly easier on my end, since I already almost do that.

I would basically empty everything to nil (which I do already) then run a large garbage collection cycle and call world:destroy() at the end of that garbage collection cycle.

It is interesting to note that you bring up garbage collection, as a similar issue was noted by someone in another thread here: [link]https://love2d.org/forums/viewtopic.php?t=9643[/link] where the solution was to garbage collect contacts before destroying the world. (Although this was in love 0.8.0, so I figured it would be fixed by now). I will have to look into this further, any other insights are welcome.

raidho36 wrote: ↑Tue Aug 06, 2019 6:03 pm I'd assume you already have a full list(s) of all of these, because otherwise the bodies get garbage collected?

This makes me wonder if the problem is precisely the fact that you get the same object after GC on it is run (the "double GC" issue recently discussed). I bet that can confuse a memoizer.

Edit: Never mind, after a peek at the source it's apparent that the problem is in the C++ side of things exclusively.

_DaCoolOne_ wrote: ↑Tue Aug 06, 2019 3:26 pm 1. I am using world:destroy() to unload the physics world, then when reloading the world I create a brand new physics world and try to replicate the fixtures (basically I'm trying to simulate launching the script again without relaunching the entire game / multiple scripts again).

It's possible your issue is fixed by LÖVE 11.3 (since there are a couple fixture and memoizer-related fixes in 11.3). You can try a prerelease nightly build of 11.3 for windows here: https://ci.appveyor.com/project/AlexSzp ... /artifacts

(or 64 bit if you want: https://ci.appveyor.com/project/AlexSzp ... /artifacts )

raidho36 wrote: ↑Tue Aug 06, 2019 5:24 pm This is a LuaJIT optimization-related error; there's a table called "memorizer" that stores all physics objects, and the error text means exactly what it says.

It has to do with LÖVE's C++ code, not LuaJIT.