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
result:
#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
TO_ROO
M */
2287
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.
So...
(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 =
-1,
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",
[snip]
wis = 11 '\013', dex = 11 '\013', con = 11 '\013'}, points = {mana =
10,
max_mana = 10, hit = -113, max_hit = 331, move = 50, max_move = 50,
[snip]
position = 0 '\000', carry_items = 0 '\000'}, player_specials =
0x80e5624,
[snip]
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