The Geek, The Bug, and The Sledgehammer

[elfs]

For the past day or so, I have had a conundrum. Freespace 2 kept crashing on me at the end of one particular mission. It didn't seem to matter how I terminated the mission so long as I didn't quit out.

So, I geeked. Freespace runs on top of X, the windowing environment for Unix. Because the windowing environment, the window manager, the desktop environment, and client programs are all independent layers, I took my laptop downstairs and proceeded to log in remotely to my desktop, then ran Freespace 2 in the debugger (gdb), with the output to my laptop. I had two screens open connected by the wireless network-- in one, I was playing the game, and in the other I was watching a real-time display of memory usage and code patterns. Very cool.

The leak turned out to be an attempt to release memory already released. I couldn't figure out how that was possible since, according to the code I saw, it was checking to make sure it did not double-release memory, so why was it trying to free something marked as already freed?

Annoyed, and wanting to play the game, I pulled out a programmer's sledge hammer. Hans Boehm's garbage collector is a library that allows you to comment out all memory freeing; instead, it routinely checks your memory tree and frees the stuff you're not using. I recompiled the game with the library enabled, having substituted the GC_MALLOC call for the routine memory allocation call.

It worked. And it was fascinating to watch my memory patterns go up and down in reliable, routine fashions. The garbage collector was freeing memory once and only once, and my game ran without a glitch. Heck, I think the performance numbers were even a little better. And it was nice to code in C, if only for a little bit. I've been wrapping my head around Javascript's lisp-like enclosures and the double-secret-wacky way object orientation is done, and I want something simple, like C, once in a while to clear my head.

Comments

[technoshaman.livejournal.com]

Nice swat. :)

[elfs.livejournal.com]

Well, then I recompiled with Optimization Level 3 on and it all went to hell, sucking up more memory than I had. I rolled back to O2, but haven't tested it yet.

[technoshaman.livejournal.com]

-O2 is generally what's considered "safe" for production code, IIRC...

The weirdo thing about gcc is that -g -O2 is perfectly legit... after all these years, having been raised on Berkeley and AT&T compilers where that was verboten, it still feels weird...

[neowolf2.livejournal.com]

On thing you have to remember about the Boehm-Demers-Weiser garbage collector is that it's a conservative collector. That is, it treats any word on the stack or in statically allocated memory as a possible 'root' that points into the heap. So, it's possible to have an integer there that keeps alive allocated memory that is actually dead. This might explain unlimited memory growth.

There are some tricks you can play with the allocator to reduce the likelihood of false roots. It helps if you don't have large linked structures where one false root can prevent large numbers of objects from being collected.

[lazarus834.livejournal.com]

I just started playing around with a program called "valgrind" which does some very interesting memory analysis while you are running - it shows you which line allocated the memory which was not freed.

[elfs.livejournal.com]

Doesn't valgrind slow the program down to a crawl? Not very useful for a real-time video game.

This wasn't a "not free" problem; this was a "free twice" problem, even though the line right above it does a check to make sure the pointer is not null.

[lazarus834.livejournal.com]

yeah, valgrind slows things down a lot. Your way is definitely better :-)

but i think valgrind can find those kinds of errors too. free twice errors are very unpredictable. I didn't know they caused memory leaks.

[woggie.livejournal.com]

You know, this is the sort of stuff I would like to be able to do, but don't have the confidence or skills to do.

Someday...