Mailing List
Home
Forum Home
MUD Dev - Discussion of MUD system design, development, and implementation
Mac Game - Mac game development
Rivers of MUD - a Diku and Merc based multiuser dungeon
SMAUG
Subjects
Getting UDP through NAT/firewalls/whatever for a game
Getting UDP through NAT/firewalls/whatever for a game
QuickTime errors
Python script as stand alone MUD server
Various sound problems
Fragment Shaders & GL TEXTURE RECTANGLE EXT
Timers and global variables
Re: Language and platform for Text MUD server
Apparent acquisition of Yantis (mysupersales) by IDE
HID keyboard
Getting UDP through NAT/firewalls/whatever for a game
Microsoft Sparkle
Director MX
Congratulations Horizons
Yet more problems fullscreen mode
Apple Dev Kitchen Them 's tasty vittles, Maw!
NSOpenGLContext, Pbuffers, and drawables
More DCR "theft " naughtiness
dynamic sprite creation and imaging lingo
Re: Find stuff in Flash array?
Effects of skill imbalances?
QuickTime errors
Rom 2 4/Quickmud Enhancement/Bug fix
Working with XML files/CFURL
smooth scrolling/subpixel tweening
RE: (Ron help me?) Flash text
Flash Racing
MudDev FAQ 2
Browser based games
Installing GLUT
Special character in Flash XML
 
Search:  
Power your search with and, or, +, -, or "some phrase" operators.
rgObjNest corruption...

rgObjNest corruption...

2004-07-12       - By Richard Lindsey

 Back
Reply:     1     2     3     4     5     6     7     8  

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.

--
ROM mailing list
ROM@(protected)
http://www.rom.org/cgi-bin/mailman/listinfo/rom

Earn $52 per hosting referral at Lunarpages.