2 Trivial bugs fixed

[johane]

Not sure this is the right place for these....

I was running World under Valgrind (memory leak checker) and found a couple of "trivial" bugs.

common/linked_list.h

template<class TYPE>
LinkedList<TYPE>::LinkedList()
{
list_destructor_invoked = false;
first = 0;
count = 0;
dont_delete = false; // ADDED this line
}



Note that the destructor for this class checks that dont_delete is false, so this prevents it ever being called with an unitialised value.


world/net.cpp

in main(), from line 238:


if (!zoneserver_list.worldclock.loadFile(EQTIME_INI))
LogFile->write(EQEMuLog::Error, "Unable to load %s", EQTIME_INI);

char tmp[20];
tmp[0]=0x00;// ADDED this
database.GetVariable("holdzones",tmp, 20);



This one gets rid of a possible error in common/database.cpp.

It's actually pretty solid without this, but this improves the style... if anyone cares.


These two fixes make Valgrind report no errors outside libc for world.

[fathernitwit]

nice, the linked list one will actually make a difference, I have seen that cause problems but never been able to track it down. Both changes have been made.


... now to get zone to run in valgrind, lol....

[johane]

... now to get zone to run in valgrind, lol....

Yeah, there's something rather odd happening with zone under emulation (valgrind is a CPU emulator). I am currently suspecting the tls libraries. But it has to wait till I can get a slightly bigger linux machine - 233MHz and 256MB seems to be just a bit small to run EMU under debuggers for some strange reason... odd that.

Glad the list thing is useful though. I'll keep trying to identify more "defects" anyway.

[fathernitwit]

this has been evaluated a few times in the past, and seems to relate to valgrind's implementation of pthread mutexes.

but yea, 233Mhz will not cut it, it barily runs on a 3.2 Ghz machine without timing out.