get_obj_type, loop

Posted by Zeno on Wed 22 Sep 2004 07:28 PM — 6 posts, 14,813 views.

USA #0
Something I want to avoid is the MUD being caught in a loop, and until now, I've succeeded. But just today, it was caught in a loop when I got home from Cisco.

0x080bc822 in get_obj_type (pObjIndex=0x82e19c8) at handler.c:2102
2102            if ( obj->pIndexData == pObjIndex )
(gdb) bt
#0  0x080bc822 in get_obj_type (pObjIndex=0x82e19c8) at handler.c:2102
#1  0x080f43ad in reset_area (pArea=0x82d8e98) at reset.c:1464
#2  0x080a6bd5 in area_update () at db.c:2517
#3  0x0811f051 in update_handler () at update.c:2189
#4  0x0809ba2b in game_loop () at comm.c:690
#5  0x0809b333 in main (argc=8, argv=0xbfffe650) at comm.c:304
#6  0x42015967 in __libc_start_main () from /lib/i686/libc.so.6

(gdb) list
2097    OBJ_DATA *get_obj_type( OBJ_INDEX_DATA *pObjIndex )
2098    {
2099        OBJ_DATA *obj;
2100
2101        for ( obj = last_object; obj; obj = obj->prev )
2102            if ( obj->pIndexData == pObjIndex )
2103                return obj;
2104
2105        return NULL;
2106    }


(gdb) f 1
#1  0x080f43ad in reset_area (pArea=0x82d8e98) at reset.c:1464
1464            if ( pArea->nplayer > 0 ||
(gdb) list
1459                    pReset->arg3 );
1460              bug( buf, 0 );
1461    */
1462              continue;
1463            }
1464            if ( pArea->nplayer > 0 ||
1465               !(to_obj = get_obj_type(pObjToIndex)) ||
1466                !to_obj->in_room ||
1467                 count_obj_list(pObjIndex, to_obj->first_content) > 0 )
1468            {

(gdb) p *obj
$1 = {next = 0x8357358, prev = 0x836f8b0, next_content = 0x8357358, prev_content = 0x836f8b0,
  first_content = 0x0, last_content = 0x0, in_obj = 0x0, carried_by = 0x0,
  first_extradesc = 0x0, last_extradesc = 0x0, first_affect = 0x0, last_affect = 0x0,
  pIndexData = 0x82b78f0, in_room = 0x82d6638, name = 0x82b7988 "blood",
  short_descr = 0x82b79a0 "the spilled blood",
  description = 0x82b79c0 "A pool of spilled blood lies here.", action_desc = 0x81c34b0 "",
  item_type = 27, mpscriptpos = 0, extra_flags = {bits = {0, 0, 0, 0}}, magic_flags = 0,
  wear_flags = 0, mpact = 0x0, mpactnum = 0, wear_loc = -1, weight = 1, cost = 0, level = 0,
  timer = 1, value = {5, 3, 0, 1, 0, 0}, count = 5, serial = 5594, room_vnum = 1023,
  ashards = 0}
(gdb) p *pObjIndex
$2 = {next = 0x0, next_sort = 0x0, first_extradesc = 0x0, last_extradesc = 0x0,
  first_affect = 0x0, last_affect = 0x0, mudprogs = 0x0, progtypes = {bits = {0, 0, 0, 0}},
  name = 0x82e1a60 "wooden chest", short_descr = 0x82e1a80 "a wooden chest",
  description = 0x82e1aa0 "A large wooden chest sits in the corner of the room.",
  action_desc = 0x81c34b0 "", vnum = 2613, level = 0, item_type = 15, extra_flags = {bits = {0,
      0, 0, 0}}, magic_flags = 0, wear_flags = 0, count = 1, weight = 1, cost = 0, value = {10,
    1, 2612, 0, 0, 0}, serial = 161, layers = 0, rent = 0, ashards = 0}


I can't print anymore, because I killed the loop. Any idea how this can be fixed?
USA #1
2101        for ( obj = last_object; obj; obj = obj->prev )
2102            if ( obj->pIndexData == pObjIndex )
2103                return obj;

Well, that seems to be the culprit, but that would mean that your linked list has gotten corrupted. Either an object's prev points to itself, or there is some other form of loop in the linked list. I can't think of any other reason why that loop would go on forever.

Of course one wonders how your linked list would have gotten corrupted in the first place. :-)
USA #2
Well pObjIndex is a container. Would that matter? I have no idea why it would be corrupt.
USA #3
pObjIndex doesn't have anything to do with it, if you look at the for loop it's stuck in it's just looping over the object linked list.

Are you sure it was looping in that for loop? It's the only loop in the code you showed, but... one never knows.
USA #4
I'm positive it was. Any idea what would cause it to become corrupt?
USA #5
Well, it would have to be some code change you made somewhere I think. Either that or e.g. you changed a structure's member ordering and didn't do a full recompile. It's kind of weird that it would happen so rarely, though.