[bf1942] Another stack trace

Zkast Net Admin admin at zkast.net
Fri Dec 13 23:58:30 EST 2002


LOL, It wouldn't feel right if my box was that easy.  
 
(gab) backtrace
#0  0x08f644c8 in dice::ref2::MemoryPool::alloc ()
#1  0x08f64558 in dice::ref2::MemoryPool::alloc ()
#2  0x08f68ab4 in __builtin_vec_new ()
#3  0x08b02473 in dice::meme::Memory::wstringDuplicate ()
#4  0x08aed191 in dice::meme::WstringData::set ()
#5  0x08b84fa3 in dice::bf::BfMenu::initHud ()
#6  0x08b8ae7d in dice::bf::BfMenu::outputMessage ()
#7  0x08ccff7e in dice::bf::GameServer::handleGameEventManagerEvent ()
#8  0x08cd49e1 in dice::bf::GameServer::processReceivedPackets ()
#9  0x08cc865a in dice::bf::GameServer::update ()
#10 0x08a9eb31 in dice::bf::Setup::mainLoop ()
#11 0x08a9e11c in dice::bf::Setup::start ()
#12 0x08a81a4d in main ()
#13 0x40077657 in __libc_start_main (main=0x8a81890 <main>, argc=1, 
    ubp_av=0xbffffb14, init=0x8a80ca8 <_init>, fini=0x960211c <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffffb0c)
    at ../sysdeps/generic/libc-start.c:129
 
 
 
-----Original Message-----
From: Gudmo [mailto:kain at fortress.is] 
Sent: Friday, December 13, 2002 10:23 PM
To: bf1942 at icculus.org
Subject: Re: [bf1942] Another stacktrace
 

rofl!!
 
I like you already Ryan!
 
-------Original Message-------
 
From: bf1942 at icculus.org
Date: 14. desember 2002 01:42:51
To: bf1942 at icculus.org
Subject: Re: [bf1942] Another stacktrace
 
> (gdb) backtrace
> #0 0x08f644c8 in dice::ref2::MemoryPool::alloc ()
> #1 0x08f64558 in dice::ref2::MemoryPool::alloc ()

Just to update y'all:

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

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

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

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

--ryan.


.


 
 
 
____________________________________________________
 <http://www.incredimail.com/redir.asp?ad_id=309&lang=9>   IncrediMail -
Email has finally evolved -
<http://www.incredimail.com/redir.asp?ad_id=309&lang=9> Click Here 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/bf1942/attachments/20021213/e5ff3c96/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 494 bytes
Desc: not available
URL: <http://icculus.org/pipermail/bf1942/attachments/20021213/e5ff3c96/attachment.gif>


More information about the Bf1942 mailing list