Welcome to the Builder Academy

Question handler.c crash

More
03 Mar 2017 13:15 #6586 by JTP
handler.c crash was created by JTP
Anyone who can tell me how to avoid the line marked in the code below suddently crashed my mud 5 times in 2 days ?
Code:
/* Extract an object from the world */ void extract_obj(struct obj_data *obj) { struct char_data *ch, *next = NULL; struct obj_data *temp; if (obj->worn_by != NULL) if (unequip_char(obj->worn_by, obj->worn_on) != obj) log("SYSERR: Inconsistent worn_by and worn_on pointers!!"); if (IN_ROOM(obj) != NOWHERE) obj_from_room(obj); else if (obj->carried_by) obj_from_char(obj); else if (obj->in_obj) obj_from_obj(obj); if (OBJ_SAT_IN_BY(obj)){ for (ch = OBJ_SAT_IN_BY(obj); OBJ_SAT_IN_BY(obj); ch = next){ if (!NEXT_SITTING(ch)) OBJ_SAT_IN_BY(obj) = NULL; else OBJ_SAT_IN_BY(obj) = (next = NEXT_SITTING(ch)); SITTING(ch) = NULL; NEXT_SITTING(ch) = NULL; } } /* Get rid of the contents of the object, as well. */ while (obj->contains) extract_obj(obj->contains); REMOVE_FROM_LIST(obj, object_list, next); if (GET_OBJ_RNUM(obj) != NOTHING) (obj_index[GET_OBJ_RNUM(obj)].number)--; <<<<This line suddently crashed my mud 5 times in 2 days, why ? if (SCRIPT(obj)) extract_script(obj, OBJ_TRIGGER); if (obj->events != NULL) { if (obj->events->iSize > 0) { struct event * pEvent; while ((pEvent = simple_list(obj->events)) != NULL) event_cancel(pEvent); } free_list(obj->events); obj->events = NULL; } if (GET_OBJ_RNUM(obj) == NOTHING || obj->proto_script != obj_proto[GET_OBJ_RNUM(obj)].proto_script) free_proto_script(obj, OBJ_TRIGGER); free_obj(obj); }

Please Log in or Create an account to join the conversation.

More
03 Mar 2017 22:31 #6587 by thomas
Replied by thomas on topic handler.c crash
GET_OBJ_RNUM() is a macro that finds the "real number" of an item. The "real number" is the corresponding index into the object index.

The line that is crashing is suppoed to make sure that the count of "current objects of this type in game" is updated correctly.
But, something is wrong about the real_number of this object. Potentially two things could be wrong here:
- it could be too low, in the negatives. This would give object_index[-234] which would obviously crash.
- it could be too high, beyond the end of the object_index. Thus object_index[1213334].number would probably point to some memory you don't control.

The check above this line is checking whether the real number is "NOTHING". Depending on your setup, either NOTHING is -1 (if indices can be negative) or the highest possible integer (if indices are limited to positive numbers). Whichever one it is, it is not very interesting. I find it highly unlikely that the real number suddenly has changed into a negative value (unless it was actually a negative NOTHING).

So, the number is corrupted otherwise.
As I see it, there are two options again:
- either the number has changed (through a memory overwrite somewhere else)
- or the object_index has changed, removing the top elements, and this is causing it to be shorter than the current rnum. This only happens one place, in genobj.c, delete_object. And this cleans up after itself.

So, this leaves only one thing - memory corruption. Sorry about that, not really what I think you wanted to hear.

Any recent changes ?

Please Log in or Create an account to join the conversation.

More
05 Mar 2017 11:38 #6588 by JTP
Replied by JTP on topic handler.c crash
Nope no changes at all for over a mounth. So very wierd and annoying.

Please Log in or Create an account to join the conversation.

Time to create page: 0.171 seconds