Member Discussions

Greetings, I'm having this problem with resets in my mud that I'm working on. We did a complete area wipe and are starting to create new original areas. The problem comes when it comes time to add in resets. Resets, both mob and obj, can be created with no problems and work correctly, but, when the time comes to do a copyover or a reboot, the resets are causing the mud to crash/not boot up.

This is the output of the core file...
#0 0x08150e74 in new_reset (pR=0x40387ba0, pReset=0x40387ed0) at db.c:1050
1050 pR->reset_last->next = pReset;

and this is the backtrace...
(gdb) bt
#0 0x08150e74 in new_reset (pR=0x40387ba0, pReset=0x40387ed0) at db.c:1050
#1 0x08151058 in load_resets (fp=0x823afc0) at db.c:1116
#2 0x0814f516 in boot_db (fCopyOver=0 '\0') at db.c:365
#3 0x08094685 in main (argc=2, argv=0xbffff704) at comm.c:404
#4 0x400657f7 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)

This is really wierding me out because I haven't even touched the reset code, I'm the only coder, so I know that no one else has done anything either.

Please hit me back with some info, Thank you in advance.

MysticVoid

Am I correct in assuming that if the mud won't execute a reboot, it also will not boot up at all due to this problem?

Correct, until I delete all the reset (which isn't a huge problem since I only have 2 areas atm).

I have two versions of my mud, the current version and a backup thats accouple months older (I know, I should backup more hehe). The problem does not exist on the backup and all the function (copyover/reset stuff, looks identical).

Would help to know the codebase (rom?) and what is in the
#RESET part of the area it crashes on. I could use my 6th
sense, but I'm sort of low on mana :)

>The problem does not exist on the backup and all the function (copyover/reset stuff, looks identical).

Any changes aside from removing the areas? It could be as simple as the code having hardcoded some vnums somewhere. I suggest first running diff between the two codebases to eliminate any source changes, then grepping for 'vnum' and 'num.'

.

Its a Dystopia mud.

Here is some more gdb info

(gdb) frame 0
#0 0x08150e74 in new_reset (pR=0x40387ba0, pReset=0x40387ed0) at db.c:1050
1050 pR->reset_last->next = pReset;
(gdb) print pR->reset_last
$1 = (RESET_DATA *) 0x0

It crashes if there are any resets period. Atm there are no resets of course, but if I do add any, Mob or Obj, it will crash apon copyover or reboot. Other then that, the resets function just fine.

I'm kinda failing to see why that would be causing problems, not ripping on your advice, I will try it, but if everything works fine (which it does), until I add a reset of an type, I don't see why hardcoded vnums would cause a prob (until of course the time comes that the mud would call the said vnum and the obj or mod doesn't exist). Adding a reset shouldn't just all of a sudden trigger the crashing....whould it??? Explaination would be greatly appreciated, I'm trying to learn as much as possible :)

Thank you

>Adding a reset shouldn't just all of a sudden trigger the crashing....whould it?

It could.

Anyway, looking at your bt from reply to scandum, how about you post us the function that crashes (if it's long then just anything from the start to the crash line?) Anytime you have a pointer value of 0x0, you're in trouble.. looks like the pR data structure may be uninitialized but I can't but guess without some code.

.

Alrighty, here is the function...

void new_reset(ROOM_INDEX_DATA *pR, RESET_DATA *pReset)
{
RESET_DATA *pr;

if (!pR)
return;

pr = pR->reset_last;

if (!pR)
{
pR->reset_first = pReset;
pR->reset_last = pReset;
}

else
{
pR->reset_last->next = pReset;
pR->reset_last = pReset;
pR->reset_last->next = NULL;
}

top_reset++;
return;
}

Thank you guys for your advice and help.

pr = pR->reset_last;

if (!pR)
{
pR->reset_first = pReset;
pR->reset_last = pReset;
}

-----------------------------

Tell me, if pR does not exist, how do you alter pR->reset_first or ->reset_last?

Very good question, but I can't answer that one hehe, ask one of the members of the teams that coded that in =P Thats stock code right there so I'm a tad clueless on how it all works. That same code is in my backupped version of the mud, and that one works perfectly.

Sound to me like your online creation/building system is broken and isn't correctly saving areas, specifically resets. It might be useful to generate a diff from an area that works correctly and one where you've added a reset and no longer works.

I don't it actually reaches that at all, anyways.

This may sound stupid, but load the function with print statements. print out things. use fflush to force the data out.

Example: if(!pReset) { printf('WARNING: pReset NULL!!!\n'); fflush(stdout); }

Check pReset. Check pR. The print statements only have to be temp until you know whats going on. I think you have a null pointer going on.

It might not be in that function, it might be a function higher. use the print/flush system to watch everything. print to a file if it scrolls too much.

If that doesn't help, keep looking. its somewhere between where you start loading an area and where you build resets. thats only a handful of functions.

Sounds like I'm going to have to go that route :( hehe better then sending the whole thing to the trash bin lol

Thanks for that advice, in the mists of my chaos I never even thought of doing that.

Oh deary me. That's some horrible coding. As the guys noted, the passage here..

if (!pR)
{
  pR->reset_first = pReset;
  pR->reset_last = pReset;
}

..is semantically equivalent to the following:

if (MysticVoid.HasParachute() == false)
{
  MysticVoid.JumpOutOfAirplane();
}

Anyway, the code will never reach that point, but it's still awfully corrupt and wrong.

A few posts ago there was a c&p from GDB printing pR->reset_last, the result being a NULL or invalid pointer. When you do the ->, you're dereferencing the pointer.. dereferencing a NULL pointer yields undefined behaviour.

Place a check to take a look what pR.reset_last is (my guess is a NULL pointer), and if so, print a bug and otherwise advance normally. If this suspicion is confirmed, find the part of code where pR.reset_last is initialized/assigned before it gets to this function (grep for it.) My guess is that it's something like

 pR->reset_last = NULL;
 ...
 if ([something is true])
   pR->reset_last = [something else];

 new_reset(pR, ...);

Hope that's of help.

.

Bingo! Good Eye!

if (!pR) {
pR->reset_first = pReset;
pR->reset_last = pReset;
}

This routine has been MODIFIED by e e cummings.

if (!pr) {
pR->reset_first = pReset;
pR->reset_last = pReset;
}

Big difference. No comment on the choice of variable names. *spit*







(Comment added by Tyche on Sun Jan 11 23:54:12 2004)

The latter is the original Dystopia code of course.

That makes things a bit clearer.. here's the code, rewritten:

void new_reset(ROOM_INDEX_DATA * room, RESET_DATA * new_reset)
{
  // pr was a useless variable

  if (room == NULL)
  {
    return;
  }

  // See if there was a previous reset
  if (room->reset_last == NULL)
  {
    // If not, this is the first one
    room->reset_first = new_reset;
    room->reset_last  = new_reset;
  }

  // A previous reset must be adjusted
  else
  {
    // Assign the new reset to be the next one from the last
    room->reset_last->next = new_reset;
    
    // That means that the new now IS the last
    // Not overwriting the last one here, only the *pointer*  to it
    // So the last still exists before this one in the list
    room->reset_last       = new_reset;
    
    // The new one does not have a next one yet
    room->reset_last->next = NULL;

    // I *hate* singly linked lists..
  }

  top_reset++;
  return;
}

I'm not sure if that'll solve the problem, though.

.

(Comment added by muir on Mon Jan 12 0:44:10 2004)

e e cummings. ahaha. boy, am i slow tonight. good one.

You should have changed the following variable name too:

   WaRnInGgLoBaLvArIaBlE_topresets++;

You have to love a standard naming convention that has a builtin deterence and punishment mechanism. ;-)

I can't believe that the little change missed my eye, I feel like a *CENSORED* lol. Thank you guys for pointing that out!!!! I'd buy ya a beer if I knew you in person hehe.

MysticVoid