world:destroy() => "A body has escaped Memoizer!"

[Whyte Vuh'uni]

Code: Select all

69	if world then
70		world:destroy()
71	end

If my world has more than 30-50 objects in it and I attempt to destroy it, this happens: http://i49.tinypic.com/14e8a5i.png

Is this an internal error, or one on my part? And can I avoid it somehow?

[Boolsheet]

Sadly, the Contact handling is unstable in LÖVE 0.8.0.

You have to make sure that all Lua references to a Contact are gone and collected before its endContact callback returns. To be safe, do a full garbage colllection there.

Code: Select all

world:setCallbacks(collisionBeginContact, function() collectgarbage() end)

I do hope this is the problem you're seeing.

[Whyte Vuh'uni]

Huh... that does indeed seem to fix it. I tried a few other things (like calling collectgarbage() right before :destroy(), or removing the 'contact' argument from collisionBeginContact), but apparently only your suggestion works.

What a peculiar bug. Anyway, many thanks!

[Boolsheet]

What a peculiar bug.

Yes, a very nasty one. It messes up the memoizer lookups if you collect too late.

[paulclinger]

Yes, a very nasty one. It messes up the memoizer lookups if you collect too late.

I ran into a very similar issue and thought I could provide some additional details that may be helpful to those seeing (or fixing) it.

The application I run crashes with a nasty "This application has requested the Runtime to terminate it in an unusual way" error on Windows and with a not much more helpful error on OSX. I got the latest Love (from the repo) to run it on OSX so that I could see where it crashes and it crashes with the following stack trace:

love::physics::box2d::World::ShouldCollide(b2Fixture*, b2Fixture*) at src/modules/physics/box2d/World.cpp:320
_ZThn24_N4love7physics5box2d5World13ShouldCollideEP9b2FixtureS4_ at src/modules/physics/box2d/World.cpp:327
b2ContactManager::AddPair(void*, void*) at src/libraries/Box2D/Dynamics/b2ContactManager.cpp:233
void b2BroadPhase::UpdatePairs<b2ContactManager>(b2ContactManager*) at src/libraries/Box2D/Collision/b2BroadPhase.h:217
b2ContactManager::FindNewContacts() at src/libraries/Box2D/Dynamics/b2ContactManager.cpp:174
b2World::Step(float, int, int) at src/libraries/Box2D/Dynamics/b2World.cpp:904
love::physics::box2d::World::update(float) at src/modules/physics/box2d/World.cpp:257
love::physics::box2d::w_World_update(lua_State*) at src/modules/physics/box2d/wrap_World.cpp:42

The exception breakpoint is triggered on the line: throw love::Exception("A fixture has escaped Memoizer!");

This thread is the only love2d related discussion on this issue I could find. Unfortunately, there is no predictable path to run into this issue, but it is reproducible. I added collectgarbage as you suggested and the issue was (almost) eliminated. The number of colliding objects in the application is between 500 and 800.

Unfortunately I can't share the application as it was provided by one of my users; and what makes it worse, the application only fails when it's suspended in my debugger (mobdebug) and then resumed (and not even every time). So far this is the only application I could find that triggers this issue.

Is there anything I can do to troubleshoot it is further? For example, to see what exactly happens with those fixtures?

Paul.

[bartbes]

Ah, yes, the pausing might actually be causing this, since the lifetime of these objects is very short, and the pause would then extend it beyond its intended goal (which causes this). For instance, it might be messing with lua's gc, causing it to not collect in time.

[paulclinger]

Ah, yes, the pausing might actually be causing this, since the lifetime of these objects is very short, and the pause would then extend it beyond its intended goal (which causes this). For instance, it might be messing with lua's gc, causing it to not collect in time.

Is there anything I can do after resuming in the debugger to avoid/minimize this situation. I tried calling collectgarbage, but it doesn't seem to be enough. Is there a way to "clean up" collision objects to make it continue without crashing? Thanks.

[bartbes]

Well, with userdata you typically have to do two gc cycles to clean it up, so you could try that, though it's a workaround at best.

[paulclinger]

Well, with userdata you typically have to do two gc cycles to clean it up, so you could try that, though it's a workaround at best.

At this point I'm good with using workarounds .

This didn't help (I just called collectgrabage twice in endContact callback). Any other suggestions I can try?

Paul.