[bf1942] Another new build...

[Victor Martinez]

Core file found. Wasn't playing when it happened so can't comment on the
situation.
Slack 8.1 4x700Mhz xeon 4gb mem

gdb) where
#0  0x4016f8c0 in main_arena () from /lib/libc.so.6
#1  0xbf7ff884 in ?? ()
#2  0x0911f507 in _STL::ios_base::imbue ()
#3  0x0013578f in ?? ()
#4  0x0913595d in _STL::basic_ios<char, _STL::char_traits<char> >::init
()
#5  0x09135bf9 in _STL::basic_ostringstream<char,
_STL::char_traits<char>, _STL::allocator<char> >::basic_ostringstream ()
#6  0x08f5fc59 in dice::ref2::Debug::Debug ()
#7  0x09410133 in dice::ref2::Debug::constdebug ()
#8  0x08fcc36b in dice::ref2::io::SWConnection::~SWConnection ()
#9  0x08fbda34 in dice::ref2::io::NetServer::_updateConnections ()
#10 0x08fc165d in dice::ref2::io::_serverReceiveThread ()
#11 0x08fbb7f2 in ReleaseMutex ()
#12 0x4004510c in pthread_start_thread (arg=0xbf7ffc00) at manager.c:291


On Sat, 2002-12-14 at 23:26, Ryan C. Gordon wrote:
> 
> Try this one on for size:
>   http://icculus.org/betas/bf1942/bf1942-lnxded-betaupdate-build-1039933525.tar.bz2
> 
> This applies over the complete install, with or without the previous
> build. Just untar it so it overwrites the binaries and README.
> 
> I fixed a metric ton of invalid memory accesses, three deferences of bogus
> pointers, and one serious memory corruption (which I'm hoping was the
> cause of all our woes).
> 
> Please try it out. Usual disclaimer applies: this works great here (but it
> always has, so this is not at all a comfort by this point, I'm sure), but
> until I get some confirmation from the field, I can't promise this won't
> crash on connect, etc.
> 
> And, for the record, valgrind is a _fantastic_ tool for tracking down
> memory bugs. If you are a programmer and aren't using this on your code,
> you really really should. It totally blows away ElectricFence (which,
> coincidentally, runs out of mmap()able address space before the server is
> finished starting...I've had that problem with efence on every major game
> I've used it with), and dmalloc, etc.
> 
> --ryan.
> 
>