Ok, I'm having an odd problem that I only ran across because I was
deleting some old pfiles and ran into an infinite loop... now just a
while back I dropped in the olc functions for medit/oedit/redit_delete,
and it appears that one of the objects that leads to this loop has been
deleted, but reading through the code, I don't see why that should be an
issue that leads to this loop... here's what happens...
In void fread_obj in save.c, the code attempts to get_obj_index on a
vnum that has been deleted... now this vnum was for a container-type
object that had items in it within this pfile, so the container's index
object has been deleted but the contents are still indexable... so
here's what happens after the get_obj_index...
if ( get_obj_index( vnum ) == NULL )
{
log_string(LOG_BUG, "Fread_obj: bad vnum %d.", vnum );
}
else
{
obj = create_object(get_obj_index(vnum),-1);
new_format = TRUE;
}
}
if (obj == NULL) /* either not found or old style */
{
obj = new_obj();
obj->name = str_dup( "" );
obj->short_descr = str_dup( "" );
obj->description = str_dup( "" );
}
fNest = FALSE;
fVnum = TRUE;
iNest = 0;
for ( ; ; )
{
as you can see, if the get_obj_index passes, it simply creates the obj
and continues, but in this case where it fails, it logs a line, then
continues to create an instance of the object anyway down below, and
from there, runs through the normal for ( ; ; ) loop that reads in the
stats of the obj, name, short descr, etc... which is why I don't see how
it could be a problem that leads to this infinite loop... so once it
reads the iNest value as 0, it then makes the rgObjNest[iNest] = obj, so
that obj is now in that nesting slot, and loading continues on to the
next obj, which is one of the contents... the get_obj_index passes for
this object, and all the way up to:
if ( get_obj_index( vnum ) == NULL )
{
log_string(LOG_BUG, "Fread_obj: bad vnum %d.", vnum );
}
else
{
obj = create_object(get_obj_index(vnum),-1); <--- This line
new_format = TRUE;
}
within gdb, if I do a "print rgObjNest[0]->name", I get the name of the
container that was just created, who's vnum had been previously
deleted... but once this create_object line executes for the first
content object, right after that, doing a "print rgObjNest[0]->name"
results in the name of the object that was just created, the first
content... which leads to, later on down when the iNest value (which is
1) is read in for that content, an infinite loop as it tries to assign
itself to its own list of contents... Any ideas? Help? Please? :D
wavewave
Richard Lindsey.
