[bf1942] New build.

[jjohnso1 at sbcglobal.net]

I just had my first gameplay related crash.  While playing on Midway in COOP
mode (yes, I know it doesn't work), I hopped into a plane on the enemy's
carrier deck.  I was the only player connected (other than the 31 phantom
bots).  Backtrace follows:

(gdb) bt
#0  0x08e0740d in dice::bf::ai::IPIUnit::setTime ()
#1  0x092b0ac3 in dice::bf::ai::IPIUnit::setTime ()
#2  0x08e07333 in dice::bf::ai::IPIUnit::IPIUnit ()
#3  0x08dfbcb6 in dice::bf::ai::AIObjectUnit::createInformationPlugIn ()
#4  0x08df7fdc in dice::bf::ai::AIObjectReal::createInformation ()
#5  0x08df7bef in dice::bf::ai::AIObjectReal::createInformation ()
#6  0x08df7751 in dice::bf::ai::AIObjectReal::getInformation ()
#7  0x08d24384 in dice::bf::ai::PlayerLODStats::update ()
#8  0x08d24b6b in dice::bf::ai::AILODManager::updatePlayer ()
#9  0x08d247bf in dice::bf::ai::AILODManager::updatePlayers ()
#10 0x08ce7067 in dice::bf::ai::AIMain::action ()
#11 0x08cb1f79 in dice::bf::GameServer::updateAI ()
#12 0x08cc9e05 in dice::bf::GameServer::simulateFrame ()
#13 0x08ca736e in dice::bf::GameServer::update ()
#14 0x08a9b751 in dice::bf::Setup::mainLoop ()
#15 0x08a9af8c in dice::bf::Setup::start ()
#16 0x08a819bd in main ()
#17 0x00187280 in __libc_start_main () from /lib/libc.so.6

Mandrake 8.2
Linux hostname 2.4.18-6mdksecure #1 SMP Fri Mar 15 01:57:24 CET 2002 i686
unknown

Other details available on request.

John

----- Original Message -----
From: <jjohnso1 at sbcglobal.net>
To: <bf1942 at icculus.org>
Sent: Monday, January 06, 2003 8:46 PM
Subject: Re: [bf1942] New build.


> I no longer see the lag problems with maps like Midway.  Not sure yet
about
> other issues.  But I noticed something trivial, but not immediately
obvious
> that might be adversely affecting others' testing and error results with
the
> new build.
>
> IF YOU ARE SEEING OLD PROBLEMS THAT RYAN THINKS HE FIXED, PLEASE READ ON.
>
> Many of you probably noticed this -- but double check that you correctly
> extracted the new TAR into the correct location.  Unlike the previous
> updates, this TAR archive does not extract into a subdirectory called
> 'bf1942-lnxded-1.2beta1' -- it simply places the binary files in the
> directory where you run the TAR command.  So, if you aren't careful,
you're
> still running all of the code from the previous update.
>
> Anyway, back to testing.  I just wanted to point that out since I didn't
see
> it mentioned by anybody else yet in this list.
>
> John
>
> P.S.  What the heck is a 'Holy Build Box' anyway?  ;)
>
> ----- Original Message -----
> From: "Ryan C. Gordon" <icculus at clutteredmind.org>
> To: <bf1942 at icculus.org>
> Sent: Monday, January 06, 2003 2:45 AM
> Subject: [bf1942] New build.
>
>
> >
> >
>
http://icculus.org/betas/bf1942/bf1942-lnxded-betaupdate-build-1041834125.ta
> r.bz2
> >
> > The crashbugs are driving me nuts, and I'm not entirely certain they
> > aren't race conditions. So I ripped the multithreading out. There's a
few
> > benefits to this:
> >
> > 1) The binary is 1.5 megs smaller (!).
> > 2) Less latency due to context switching and mutex contention, etc.
> > 3) Less context switches.
> >
> > The end result is that the server might actually respond better and eat
> > less CPU (although I suspect the lag people are seeing is unrelated).
> >
> > Most importantly:
> > 4) No race conditions.
> >
> > No, most importantly:
> > 5) No more complaints that there's three copies of the game running!
> >
> > You might get all the same crashbugs in this build as the last one. We
> > won't know until you try it, but it will let us rule out a threading
> > problem (and at least I can say with certainty that you won't crash in
> > pthread_mutex_lock() anymore.  :)  )
> >
> > Other stuff:
> >
> > 1) The server status info (the little red dot in the server browser)
> > shouldn't be red anymore. That thing is based on framerate, but since
all
> > the video stuff was ripped out of the Linux server, the frames per
second
> > was always zero (which, I guess, is really really slow.  :)  ). Now it
> > reports server frames per second, which in terms of a null rendering
> > device, is a more accurate term for the exact same thing.
> >
> > 2) I set the gamespy socket to "reusable", which is the ONLY difference
> > between the game's socket and the gamespy one...if this doesn't fix
> > FreeBSD's binding problems, I can't fathom what's wrong with it.
> >
> > Ok, I'm getting on a plane for San Francisco now, but I'll be checking
> > email throughout the week. Please report success and failure (and stack
> > traces).
> >
> > Good luck,
> > --ryan.
> >