search

supertuxkart-sourceforge-migration / stk-migration-test2

0 stars 0 forks source link

SuperTuxKart leaks some memory every time I click Setup New Race #404

Open supertuxkart-sourceforge-migration opened 10 years ago

supertuxkart-sourceforge-migration commented 10 years ago

Author: nathanm32292394

In KartModel::attachModel in kart_model.cpp, m_wheel_node[i]->grab() isn't balanced with a drop() call. This causes some memory to be leaked every time a new race is started. The first time I noticed this, it was leaking 130KB. Then I tried a few ways of reproducing the bug to see if the size of the memory leak as reported by Valgrind would increase. Valgrind reported that Super Tux Kart leaked 1,407,476 bytes just by starting a new race maybe a dozen times. Commenting out the grab() call fixes the bug.

Migrated-From: https://sourceforge.net/apps/trac/supertuxkart/ticket/404

supertuxkart-sourceforge-migration commented 10 years ago

Author: nathanm32292394 The patch is at: http://pastebin.com/z0EiYPPi

supertuxkart-sourceforge-migration commented 10 years ago

Author: hikerstk This patch is incorrect: the grab calls are balanced with a drop (see line 145), and the wheel scene nodes will actually be removed when the kart scene node (which has a pointer to the the wheels) is removed). With your 'patch', the wheel nodes will be removed in the destructor of kart_model, then when the kart scene node is freed, stk crashes when it tries to free the wheels again.

I am leaving this ticket open for now, since I will be doing valgrind runs before 0.7.3.

Thanks a lot! Joerg

supertuxkart-sourceforge-migration commented 10 years ago

Author: hikerstk By r9981 we have fixed all leaks in STK (we could find so far). There are still some remaining leaks of libraries we are using (irrlicht, openal, X), nothing we can do about those, but they are 'one time' leaks, i.e. nothing that will accumulate over time.

Note that it is normal that memory usage might increase from one track to another, since e.g. particle systems might be cashed, textures (e.g. for new menus) will be created, ... - so a memory increase by itself is not necessarily indication of a leak (though of course if memory keeps on increasing it would indicate a leak).

I am closing this ticket now, but we will be doing more valgrind runs in the future.

Cheers, Joerg