[GDB][Long] Wierld crashes been plaguing me, now I ask for help... "16394"

From: Chris Jacobson (fear@ATHENET.NET)
Date: 09/16/97

Please, if you have ever had crashes in "act" being called from "damage"
on rare occurence, when dealing with a death blow, read this, or if you
are experienced in matters of odd odd ODD bugs/crashes...

I have been having wierd crashes occassionally - whats wierd is now
lately it seems to only happen when >I< am not on (which is 23 hours a
day - ugh :-).  However, checking core files produces the following

#0  0x804cba1 in act (
    str=0x8244c28 "$n kills $N instantly with a shot in the head!",
    hide_invisible=0, ch=0x8267888, obj=0x0, vict_obj=0x82f5ec8, type=3)
    at comm.c:2291
2291        to = world[obj->in_room].people;

Hm... to = world[obj->in_room].people.  Looks like obj->in_room isn't
valid.  But obj=0x0.

(gdb) list
2286      /* ASSUMPTION: at this point we know type must be TO_NOTVICT or
M */
2288      if (ch && (ch->in_room != NOWHERE)) {
2289        to = world[ch->in_room].people;
2290      } else if (obj && (obj->in_room != NOWHERE)) {
2291        to = world[obj->in_room].people;
2292      } else {
2293        log("SYSERR: no valid target to act()!");
2294        return;
2295      }

Ok, so that to=world line can only be called "if (obj && (obj->in_room !=
NOWHERE))".  But Obj = 0x0, so that line can never get called.  Wierd.
But I remember someone saying that sometimes GDB reports wrong when
memory calls are bad.

(gdb) print ch
$1 = (struct char_data *) 0x8267888

Ok, ch is not 0x0.

(gdb) print *ch
$4 = {pfilepos = 1074426840, nr = 29656, in_room = 16394, was_in_room =
  temp_was_in = 217, player = {
    passwd = "\000\000\000\000\000\000\000\000\000\000",
    name = 0x81e2bb0 "nurse male military",
    short_descr = 0x81e2bc8 "a military nurse",
    long_descr = 0x81e2be0 "The nurse watches closely as the Science
Officer beg
ins the first incision.\r\n",
    wis = 11 '\013', dex = 11 '\013', con = 11 '\013'}, points = {mana =
    max_mana = 10, hit = -113, max_hit = 331, move = 50, max_move = 50,
    position = 0 '\000', carry_items = 0 '\000'}, player_specials =

Hmm, looks like the beginning data is bad, as if something wrote to the
beginning of ch.  But I looked over the code, did searches for (*ch) =
and *ch = and such, and nothing.  Looks like the REST of the data is ok.
However, hit = -113, so ch is dead, but position = 0, damage is called by
ch being the attacker.

But notice in_room = 16394... odd

(gdb) print top_of_world
$3 = 2317

This shouldn't be happening.  However, on ALL the crashes, the in_room
has ALWAYS been the same: '16394'.  This isn't some random data... its
downright confusing!  I used to have these crashes previously, but I had
thought I had fixed it by making "acid_burn" non-event based (just a
single burn instead of repetetive burns), where a weak mobile that might
be killed by the event continued to do things.

So I put this handler in my damage() call (right in the beginning)

        if (ch && (IN_ROOM(ch) == 16394)) {
                mudlogf(BRF, LVL_STAFF, TRUE, "SYSERR: SERIOUS ERROR!!!  ch (%s) in
damage() is @ 16394!", GET_NAME(ch));
                return 1;
        } else if (victim && (IN_ROOM(victim) == 16394)) {
                mudlogf(BRF, LVL_STAFF, TRUE, "SYSERR: SERIOUS ERROR!!!  victim (%s) in
damage() is @ 16394!", GET_NAME(victim));
                return 1;

So technically, I would think this would catch it... but it doesn't.  It
still crashes, and ch->in_room is always 16394.  I think the other data
(pfilepos and nr) is always the same too, but I'm not sure, ch->in_room
was just something that was obvious to me.

I did searches for 16394, 400A, etc throughout my entire source, nothing.
 Its sooo wierd.

And worst of all, this is not a regularly reproduceable crash... I don't
know whats going on.

- Confused and Baffled
  Chris Jacobson

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |

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