[bf1942] Another new build...

Damon damon at daycross.com
Sun Dec 15 18:23:15 EST 2002


;p thank u both

i used ur directions and did get some different bits :) here

(gdb) bt
#0  0x298229b6 in __sigsuspend (set=0xbfbfee78)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
#1  0x297e6d6d in __pthread_wait_for_restart_signal (self=0x297f04a0)
    at pthread.c:969
#2  0x297e8acb in __pthread_alt_lock (lock=0x2c5adc50, self=0x0)
    at restart.h:34
#3  0x297e4fb6 in __pthread_mutex_lock (mutex=0x2c5adc40) at mutex.c:120
#4  0x8fbb75c in ?? ()
#5  0x8fbd0b2 in ?? ()
#6  0x8cc8bec in ?? ()
#7  0x8cc37ca in ?? ()
#8  0x9235868 in ?? ()
#9  0x8aaf0f4 in ?? ()
#10 0x8ab0591 in ?? ()
#11 0x8cea06c in ?? ()
#12 0x8ce6e78 in ?? ()
#13 0x8cf5047 in ?? ()
#14 0x8cc866e in ?? ()
#15 0x8a9eaf1 in ?? ()
#16 0x8a9e0dc in ?? ()
#17 0x8a81a0d in ?? ()
#18 0x29810336 in __libc_start_main (main=0x8a81850, argc=1,
    ubp_av=0xbfbffc6c, init=0x8a80c74, fini=0x960159c,

still muchos mem locations, this any better?

Damon



-----Original Message-----
From: Brad Davidson [mailto:kiloman at oatmail.org]
Sent: 15 December 2002 23:49
To: bf1942 at icculus.org
Subject: Re: [bf1942] Another new build...


That and he needs to load the binary... without the binary loaded, gdb has no
idea what sub he's in at that memory location.

gdb -e ./bf1942_lnxded -c bf1942_lnxded.core
once it loads to the (gdb) prompt, give it the 'bt' and post that.

A little more usefull than a list of memory locations :P

-Brad

On Sun, 15 Dec 2002 at 11:27:45, Killing wrote:
> Damon link the linux compat lib dir to the main lib dir to get useful
> info from your stack trace:
> ln -s /usr/compat/linux/lib /lib
> 
>     Steve / K
> ----- Original Message ----- 
> From: "Damon" <damon at daycross.com>
> To: <bf1942 at icculus.org>
> Sent: 15 December 2002 13:40
> Subject: RE: [bf1942] Another new build...
> 
> 
> Hi.
> Worked so well for so long :(
> 
> STUB: try to do without {BFMainNewRend/Setup.cpp:1513}
> Abort trap (core dumped)
> $gdb --core=bf1942_lnxded.core
> Core was generated by `bf1942_lnxded'.
> (gdb) bt
> #0  0x298229b6 in ?? ()
> #1  0x297e6d6d in ?? ()
> #2  0x297e8acb in ?? ()
> #3  0x297e4fb6 in ?? ()
> #4  0x8fbb75c in ?? ()
> #5  0x8fbd0b2 in ?? ()
> #6  0x8cc8bec in ?? ()
> #7  0x8cc37ca in ?? ()
> #8  0x9235868 in ?? ()
> #9  0x8aaf0f4 in ?? ()
> #10 0x8ab0591 in ?? ()
> #11 0x8cea06c in ?? ()
> #12 0x8ce6e78 in ?? ()
> #13 0x8cf5047 in ?? ()
> #14 0x8cc866e in ?? ()
> #15 0x8a9eaf1 in ?? ()
> #16 0x8a9e0dc in ?? ()
> #17 0x8a81a0d in ?? ()
> #18 0x29810336 in ?? ()
> (gdb)
> FreeBSD 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Wed Oct  9 15:08:34 GMT 2002
> 
> well... its what i got!!!
> 
> Damon
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Damon [mailto:damon at daycross.com]
> Sent: 15 December 2002 09:33
> To: bf1942 at icculus.org
> Subject: RE: [bf1942] Another new build...
> 
> 
> 
> Hi.
> So far so good. Fresh install of bsd4.7 on a athlon 1400 512mb. boots fine,
> map change fine.
> Thx,
> Damon ( Dc|| in the quakenet channel ;p )
> 
> 
> 
> 
> -----Original Message-----
> From: Ryan C. Gordon [mailto:icculus at clutteredmind.org]
> Sent: 15 December 2002 07:26
> To: bf1942 at icculus.org
> Subject: [bf1942] Another new build...
> 
> 
> 
> Try this one on for size:
> 
> http://icculus.org/betas/bf1942/bf1942-lnxded-betaupdate-build-1039933525.ta
> r.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.





More information about the Bf1942 mailing list