Re: Seg. fault, multi-attack

From: Paul Cole (pcole@ccwf.cc.utexas.edu)
Date: 09/21/95


On Wed, 20 Sep 1995, Rasmus Rxnlev wrote:

[ some non-relevent portions snipped]

> It seems as if my fight.c code is the 'nasty bugged' code.
> I implemented multiple attacks, and to make thge situation clearer I've 
> decided to post my (very short) way of implementing it ... (wich I by the 
> way beleave is the thing that causes the bug).
> 
> in the perform_violence() routine I've added the following:
>  
> hit(ch, FIGHTING(ch), TYPE_UNDEFINED);
> 
> if (MOB_FLAGGED(ch, MOB_SPEC) && mob_index[GET_MOB_RNUM(ch)].func != NULL)
>    (mob_index[GET_MOB_RNUM(ch)].func) (ch, ch, 0, "");
> 

> 
> if(GET_SKILL(ch, SKILL_SECOND_ATTACK))
>     hit(ch, FIGHTING(ch), TYPE_UNDEFINED);
> if(GET_SKILL(ch, SKILL_THIRD_ATTACK))
>     hit(ch, FIGHTING(ch), TYPE_UNDEFINED); 

Notice that you are hitting the victim twice in a row with no logic 
controls.. I'll show why this is important down there |
                                                      |
> Now, when I run this on my own Linux mashine (with and without gdb) the 
> mud seems to run perfectly... 
> 
> Now when i transter the source (and only the soure, not pfiles! 8) I 
> allso compile the source without errors on teh SunOS.. 
> 
> Now, if I start a fight on the SunOS mashine I get some combat messages, 
> and then the mud crashes... 
> 
> when using gdb it said it crashed in line 765 of the fight.c code... 
> this is in the hit() procedure... 
> 
>  (line 765:)    if (ch->in_room != victim->in_room) {
>                   if (FIGHTING(ch) && FIGHTING(ch) == victim)
>                      stop_fighting(ch);
>                      return;
> 
> [UNCUT]

*** Speaking of the hit's in perform violence routine far above ***

It is my belief that you are not checking to see if the previous hit
routine killed the victim <or if you've got some modifications, the
attacker....> and such an occurance will crash your program.  

  [ Ouch, speaking of the attacker dying, I just thought of a situation ]
  [ that can crash my own mud too! Wonderbar.                           ]

Why?

Because on line 765 in hit() you are trying to dereference the victim and
attacker structures which aren't guaranteed to be valid, since one or both
might have died in the previous hit() which would have caused the
character structure to be freed. 

And as we all know <or should know>, trying to derefence an invalid 
pointer will cause the operating system to say 

  "Whoah! Hold on there bud! That memory isn't assigned to you!
   sig: SEG FAULT
   core dumped"

> This is as far as I could trace the bug... it seems as if the problem 
> arises when the ch->in_room  ot victim->in_room is evaluated... but on 
> the other hand, if this is the case it should crash on both mashines... 

So, what do I suggest?  Examine your death procedures and check to see how 
it modifies the attacker when the victim dies.  If your setup the way I 
am, you'll find that the test IS_FIGHTING(attacker) will be false if the 
victim has met an uncertain demise so you can add those to your 
perform_violence routine such as...

 if( (IS_FIGHTING(ch)) && (GET_SKILL(ch, SKILL_SECOND_ATTACK)) )
     hit(ch, FIGHTING(ch), TYPE_UNDEFINED); 

  --Paul Cole
  Stil @ Forbidden Lands
--
  Shameless Plug: Forbidden Lands Mud 
		which will return soon @ soon.to.be.announced 5000
				       & http://soon.to.be.announced/flmud



This archive was generated by hypermail 2b30 : 12/07/00 PST