moveWithCollisions() causing memory leak?

C-API / SDK 1.12.3 on Linux.

In my sprite update function, if I move my sprite:
playdate->sprite->moveTo( alien_ptr, cx, cy );

I have no issues.

However, if I move my sprite:

int collision_count;
SpriteCollisionInfo *collisions = playdate->sprite->moveWithCollisions( alien_ptr, cx, cy, NULL, NULL, &collision_count );
playdate->system->realloc( collisions, 0 );

I see a ever-increasing memory usage. I'm reasonably sure there are no collisions occurring during either move operation.

Is there some further clean-up that needs to be done after calling this function?

(aside) I rely on the collision handler functions being called, and have no use for the array returned. It would be good if there was a version of this function that did not allocate the list. Or at least one that I could pass a list to, that would save the malloc().

I run the code through valgrind, and I can see the leak being found, but the functions it's reported in seem to be weird - at first I thought the leak was in the simulator memory panel.

==69686== 2,188,032 bytes in 11,396 blocks are definitely lost in loss record 12,266 of 12,267
==69686==    at 0x4849013: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==69686==    by 0x3F2680: MallocFrame::AllocationList(double*) (mallocframe.cpp:254)
==69686==    by 0x3F29DF: MallocFrame::Refresh() (mallocframe.cpp:163)
==69686==    by 0x8FAC30: wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /home/sando/Code/Play.Date/PlaydateSDK/PlaydateSDK-1.12.3/bin/PlaydateSimulator)
==69686==    by 0x8FB99C: wxEvtHandler::SearchDynamicEventTable(wxEvent&) (in /home/sando/Code/Play.Date/PlaydateSDK/PlaydateSDK-1.12.3/bin/PlaydateSimulator)
==69686==    by 0x8FBB33: wxEvtHandler::TryHereOnly(wxEvent&) (in /home/sando/Code/Play.Date/PlaydateSDK/PlaydateSDK-1.12.3/bin/PlaydateSimulator)
==69686==    by 0x8FBBDE: wxEvtHandler::ProcessEventLocally(wxEvent&) (in /home/sando/Code/Play.Date/PlaydateSDK/PlaydateSDK-1.12.3/bin/PlaydateSimulator)
==69686==    by 0x8FBCE0: wxEvtHandler::ProcessEvent(wxEvent&) (in /home/sando/Code/Play.Date/PlaydateSDK/PlaydateSDK-1.12.3/bin/PlaydateSimulator)
==69686==    by 0x634DD9: wxWindowBase::UpdateWindowUI(long) (in /home/sando/Code/Play.Date/PlaydateSDK/PlaydateSDK-1.12.3/bin/PlaydateSimulator)
==69686==    by 0x579E22: wxFrameBase::UpdateWindowUI(long) (in /home/sando/Code/Play.Date/PlaydateSDK/PlaydateSDK-1.12.3/bin/PlaydateSimulator)
==69686==    by 0x579FFC: wxFrameBase::OnInternalIdle() (in /home/sando/Code/Play.Date/PlaydateSDK/PlaydateSDK-1.12.3/bin/PlaydateSimulator)
==69686==    by 0x6368BC: wxWindowBase::SendIdleEvents(wxIdleEvent&) (in /home/sando/Code/Play.Date/PlaydateSDK/PlaydateSDK-1.12.3/bin/PlaydateSimulator)
if (collision_count) playdate->system->realloc( collisions, 0 );

should fix this, see: Realloc allocates 16 Bytes of memory when pointer is NULL and size is 0

4 Likes

Oh Bother! Thanks for that. I was so stressed for hours trying to chase this one down.

Oh man, this just saved me a lot of time tracking down 1 item of leaking memory.
Got to get more defensive about my frees!

2 Likes