EQEmulator Forums - 2 Trivial bugs fixed

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=590)

- - 2 Trivial bugs fixed (https://www.eqemulator.org/forums/showthread.php?t=19455)

2 Trivial bugs fixed

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

Code:

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:

Code:

 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.

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....

Quote:

Originally Posted by fathernitwit

... 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.

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.