Am Freitag, 16. März 2007 schrieb Thomas Rösner: > jwf schrieb: > > On Thu, 2007-03-15 at 04:38 -0800, The Watermelon wrote: > >> On 3/15/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > >> Besides the guy in the forums? No... > >> IF this is another 64bit problem, then maybe there is some > >> pointer failure > >> going on, resulting in NULLDROIDs getting produced? Or instead > >> of selecting a > >> correct droid (in the target selection algorithm) it selects a > >> NULLDROID > >> which came from hell knows where? > >> Sounds a bit weird... I can't really make up a reasonable way > >> where this bug > >> should come from. :( > >> > >> --Dennis > >> > >> doesnt seem to be a pointer problem,or it should segment fault rather > >> than giving a integer-divided-by-zero exception...I dont think wz can > >> magically jump onto some memory location with all bits set as '0' like > >> you described... > >> > >> > >> I think gerard_ has a working 64bit wz trunk version,maybe he can help > >> reproducing/debugging this weird bug... > > > > I also had this SIGFPE, on a 32 bit linux system. the patch to ai.c that > > I posted to this list on the 5th works around the crash by skipping the > > calculation when it would devide by zero. > > > > for what it's worth, on a couple occasions this happened just when a > > vehicle was shown destroyed. > > Ah, that makes sense. I skipped the calculation, too, but thought it'd > just error out at another place and when it worked I was surprised, but > if it's just the remains of a dying droid about the be cleared anyway, > then it's probably safe to ignore it. It might be safe to ignore it, but the real problem is: Why does the NULLDROID exist in the 1st place? When it died, shouldn't it be removed immediately and completely instead of just partly? Why is the dead droid replaced with a NULLDROID at all?
Description: PGP signature
_______________________________________________ Warzone-dev mailing list Warzoneemail@example.com https://mail.gna.org/listinfo/warzone-dev