Sign in to follow this  

Bug squashing: tracking down a memory leak.

This topic is 4841 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone, I just wanted to write down a little adventure I had tonight with the hopes that it may help others who run into similar situations. As the title might imply, the adventure was tracking down and squashing a small memory leak. First, a short background. I am currently a hobbyist programmer. I've taken a few courses, but nothing beyond the equivalent of Freshman CS. I do blackbox QA work for a living though. My current project is a 2d, turn-based, multiplayer strategy game along the lines of Civilization/Master of Magic/Imperialism. It's my first graphical project [or rather it's my first project that didn't hit a showstopper roadblock before getting that far...]. It's fairly far along, clocking in at a heafty 20,000 lines of code, and more importantly is to the point where gameplay can be implimented rather than infrastructure. I noticed the bug while checking on some input changes I made yesterday. While simply sitting in the lobby, connected to the server the windows task manager indicated a 4k increase in resident memory every 20 seconds or so. A simple memory leak. The input changes worked like they were supposed to, so I set upon recreating the memory leak bug. I restarted the server, restarted the game, and connected up. A few moments later, the memory bumped up, and continued as the game sat there. Then it was time to whittle away possible causes. There shouldn't have been any network traffic occuring, but there shouldn't have been any graphical changes occuring either. I decided to try and exclude network traffic as a cause, as it was the simpilest to exclude. Restart game, this time not connecting to the server. Memory leak persists. Hmm, not there. That left the rendering loop, the windows message loop, the timer loop, and the actual network input loop. The network input loop can't be causing leaks, as it isn't connected to anything. The first thing it does is return if un-connected. Next I edited the code to prevent the render loop from running. It's a simple thing to comment out one line, and will narrow the possibilities down greatly. The windows message loop and timer loop always run, and are more messy to disable. A re-compile later, and it looks like the leak is in the rendering code for the lobby. No great suprise there, though I'm not sure where anything is allocated there to cause the problem... So I load up the original code into the debugger, and run to the loading of the lobby. Step step step through looking for news and deletes. Found a corner case crash bug, fixed that, but the memory leak persists. Nothing really outstanding. The player list refreshes every so often, but it didn't have anything noticable... The FPS meter changes while the game is sitting there, but it doesn't allocate anything... I decide to try a different method. I start commenting out the various class render functions that the lobby uses. Thankfully the render loop design makes this fairly trivial to do. Comment, recompile... leak. Comment, recompile.... leak. And so it goes until reaching something that does fix it. So it was [as always for hard to find bugs] a one line problem. The problem was not with the playerlist which refreshes every so often, but with the player details panel. When the playerlist refreshed, it told the player details panel to regenerate its content. The bug was simply that when the player details panel went to flush the old content, it flushed the container list [but not the contents]. The new content was regenerated, meaning the display didn't change. The old content was no longer part of the render loop, and became the leak. And the actual calls
//ro->nuke(&ro);
ro_deltree(ro);
are similar enough to cause the previous inspection to miss them. Anyways, I hope this is helpful to some people out there.

Share this post


Link to post
Share on other sites

This topic is 4841 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this