[bf1942] Another stacktrace

Greg itooo at itooo.com
Fri Dec 13 21:01:55 EST 2002


tried to compile with lib electric fence (or equivalent) ? should help
you
--------------
Saturday, December 14, 2002, 2:37:48 AM:


>> (gdb) backtrace
>> #0  0x08f644c8 in dice::ref2::MemoryPool::alloc ()
>> #1  0x08f64558 in dice::ref2::MemoryPool::alloc ()

RCG> Just to update y'all:

RCG> As you might have guessed, this is almost certainly a memory corruption
RCG> bug. The reason that almost all of the stacktraces end with two calls to
RCG> that alloc() method is because we keep a linked list of MemoryPool
RCG> objects, and if there isn't space in a given memory pool, we call alloc()
RCG> in the next pool in the linked list...but if we piddled over memory we
RCG> either corrupt the next pool or corrupt the pointer to it, so it pukes,
RCG> but not necessarily anywhere near where the actual corruption occurred,
RCG> depending on how big the memory pool was, etc.

RCG> This is why some people are getting crashes and others aren't, and why
RCG> some people can play for ten minutes, some for an hour, etc...and why I
RCG> never crash. I've got a blessed box, apparently. But rather than ship the
RCG> server with an icon that reads, "Best Played On Ryan's Development Box",
RCG> I've decided to fix this.  :)

RCG> In my local tree, I've moved to a simpler form of memory allocation so I
RCG> can track down the problem(s). Among other things, it'll let me
RCG> run the thing through valgrind and get more meaningful results.

RCG> More updates when I have them...may not be tonight. Again, thank you for
RCG> your patience; I'm trying to fix this "codesalat" as quickly as I can.

RCG> --ryan.




More information about the Bf1942 mailing list