Ok. So I think I've come to a conclusion that ever since Zeno had changed his compiler, I have had the memory leak problem. I have not compiled my player port since Zeno switched and it runs fine. I have compiled my Beta port and it crashes. When I copied my player port folder and then compiled it, it had the same memory leak bug. I have talked to David about the warnings that the new compiler caused on compile, but he stated that they shouldn't be the ones that cause the memory leak.

So I just need to be able to compile it on Zeno's old compiler and it should be fine. But I have had problems with trying to use the old compilers to work. So we'll see what happens.

I'll look into reinstalling the old gcc (new gcc will stay).

Try toning down the optimization on the compiler. Raudhrskal@Dead_Souls suggested gcc -O0 (Crat apparently said something to but I didn't see it.).

Ok, a few thoughts on this:
First, the term memory leak has meaning. It refers to when a program allocates memory on
the heap and releases the pointer without freeing it. A memory leak does not cause a crash
(at least not until you try to reference the NULL pointer you get when you finally exhaust the
heap). From all the info given here, there is nothing that points to a memory leak at all. I do
realize that some newbie coders and admins do use the term to mean a crash or other problem,
but as it is one of my pet peeves, I thought I would at least try to clear it up.

As far as the compiler goes: There are really two things that could be going on. The new compiler
is bugged and should really be removed (I rather doubt this is the case) or, there is a real problem
with the MUD. The problem might be showing as a crash here from different setting of the heap,
some extra code that the new compiler puts in or even just a different memory layouts. What ever
the reason, the real problem should be fixed.

Looking at the info given, it is pretty clear (like a couple others have said) that a stack buffer (probably
a non static function buffer, known as automatic in C/C++ terms) is overrunning, and corrupting the
stack. This type of thing is probably happening in a prior call to a function and not in the functions
in the stack back trace at the time of the crash.

Taking the info in the back trace, the code base mentioned and making an assumption about the CPU
in use (that is is little endian), this pointed me to an extra description in object vnum 3377 in
midgaard.are. It seems this description is longer then MAX_STRING_LENGTH (probably the size of
the buffer in your save function, or maybe in the strip_cr() (the overrun data has only a linefeed, so
I assume it is from after the \r are removed for saving)). I would either shorten the string, or make
MAX_STRING_LENGTH longer (or at least make sure all the buffers used are large enough). It would
also be good to have the loading (and editing) function limit the string size so you don't have overruns
like this in the future.

The problem looks to me like a classic buffer overrun. Valgrind is usually pretty good about spotting those when they happen. I also seem to recall seeing somewhere that the latest gcc compilers have some kind of flag to detect these at compile time, but I'm not 100% sure of that right now. That might be worth investigating assuming the flag works with the way some of these codebases are setup.

No, you can't detect all of these at compile time. The newer compilers have some support for arrays allocated on the stack, but as a general problem it is theoretically impossible for the compiler to know if a buffer overflow is possible at a given line of code.

At this point, it might be worth trying to compile this code on a different machine, for example a virtual machine that can be set up easily at home. Use a distribution that lets you intelligently manage packages like Debian or Ubuntu, so that you can install several versions of gcc and try with each.

Also, somebody mentioned using the standard memory routines so that valgrind doesn't get confused – that might be something to look into, but it might also be quite difficult as the code in question might be fairly complicated.

If it IS a buffer overflow, this is one of the primary reason I force anyone who will listen to be to STOP using sprintf() and start using snprintf()! Likewise for strncpy()…. Those are length-limited versions where you can specify the buffer length and avoid overflows entirely. In places where it matters (such as loading/saving data), you can check the length that actually got printed to make sure you didn't get truncated.

Yes, it's a pain, but is having your game crash NOT painful?

I compile with CYGWIN on my computer at home and it runs fine. I think I have gcc 3.3.6 or one below that…not sure as it's pretty old.

I have been thinking about setting up andlinux on my machine at home.

***EDIT***
Is it possible to set up UBUNTU on my Windows computer? or would I need to reinstall windows if i wanted both?

Sure, you can set it up by downloading VMWare's free player application. They have pre-bundled Ubuntu distributions as well. You probably want to find a "Desktop Ubuntu" system with a recent version (say 8.10) and use that.

It's rather unusual for a compiler upgrade to cause something to break like this, but that does seem to be where the evidence is pointing…

You could also set up a Dual Boot and actually install a full on version of Ubuntu. But if you do that, remember to install Windows first, and then Ubuntu as windows is not fond of working well with other OSs.

bleck…it's a bittorrent file with only 2 seeds. Downloading at 14kbps…heh

EDIT:

Found an actual download. Downloading it now.

You can also install linux in a VM, if you don't want the hassle of dual booting. I use VMware, but there are also free VM systems that probably work just as well. If they support bridged networking, you can even have people connect as if it were a totally seperate machine.

Of course, I don't bother with a desktop for such a purpose, and use plain old debian. :)

Well, I found what was causing the overflow…lol.

This was on an extra description:

We began our journey about mid-morning. We had hoped to get an early
start, but were held up while we waited for the shops to open so that
we could gather supplies for our expedition. The three of us were eager
to leave town after having either stolen from or killed nearly every
shopkeeper in Greyhawk. The locals were not happy about our presence and
as such, we feared the Executioner might decide to take some action 
against us if we remained. It was Hogar who had caused most of our 
problems, but he also was a necessary part of our team. No one could
equal his skill with the sword, at least none we had previously encountered…
Whirl often tries to get Hogar to see how unnecessary a lot of his fighting
is, but he doesn't seem to listen to her divine guidance. I suppose that
as a thief, I usually end up doing a lot of the more mundane, but necessary
actions to get us where we need to go.  However, I enjoy the adventures I've
shared with these two, especially Whirl.  Without her, where would we, in 
fact, where would I be now? 

        Well, we set off from Greyhawk along the river heading west away 
from town, and although in full view due to the daylight we wanted to avoid, 
the locals seemed more glad we had left than angry enough to give chase. 
We went under the bridge which crosses the river and continued west.  As we 
continued west there wasn't too much to see, the forest seemed to
grow darker as we moved, and long shadows seemed to be hiding some secret
danger, however nothing became of it.  Gradually we came to a split in the 
river where it appeared to go around an island, which was more shadowed than
even the forest had been.  After some thought, we decide to brave it and
found a small spot where we could land and walk on the island's south side.
Following a farely difficult path, we found a small domocile.  Whirl seemed 
to be upset about something here, and strangely so was Hogar, so we decided
not to press further and quickly left the island to continue going west along
the river. 

We noticed quickly that the river was getting much wider now, 
and soon were at the mouth of the great river.  Not wanting to get too far
from land just yet, we entered the ocean and went south along the shoreline.
I must say at this point my arms were getting tired of paddling, so Whirl
graciously cast a spell which cause my body to have a density less than that
of air! Whirl did the same to Hogar, and this seemed to life our spirits a
little, as the going was made easier.  I wonder why she didn't think of this
sooner? Moving with the speed of the wind, we begin to find ourselves
reaching colder waters.  Reaching a point where we could no longer go south,
we continued to the west.  Wow!  It's a good thing Whirl cast that spell, the

waters here are so rough, I wonder how we would have survived in those canoes.
Another turn to the south leads us to much colder waters, we can see icebergs
floating in the ocean below us.  I'm getting dreadfully cold now and wish
we could turn back, but it seems we cannot and continue onward to the south.

        This is going to be my last entry.  It has been two days since last 
I wrote.  We encountered an enormous white bear which so surprised us, it 
managed to mortally wound Hogar, and I suffered several cuts before the bear 
finally succumbed to the combined efforts of Whirl and I.  She had tried 
desparately to help Hogar during the battle and afterwards, but the cold, along
with the seriousness of the wounds told us he wouldn't make it.  Hogar died 
shortly there after. I'm afraid there may be more of those horrible beasts
in this place, but we can no more go forward, than we can go back.  At least
I am with Whirl.  The bear meat should be enough to keep us alive for a
little while, time enough for us to finally be alone together.
….

        This journal entry is one of many found in a book which had floated
in the ocean protected by some magical force from the water and salt.  The
finder can only guess at what happened to the two who were left alive there
in the cold alone, but hopes that the knowlege from the book will help 
others avoid the same fate.

I don't even know how long that's been in the area files. I found out where to look because I did the medit then save thing and then did a yell and the overflow went into the yell.

yell hey
You yell 'om the book will help 
others avoid the same fate.
hm the book will help 
others avoid the same fate.
em the book will help 
others avoid the same fate.
ym the book will help 
others avoid the same fate.

So after I deleted those extra descriptions it ran like normal (for now). I will continue to test it to make sure. Yes, the description editor needs a limit on it. Need to figure out how to do it.

***EDIT***
This is the exact item that Sharmir pointed out. It seems that the creators of the Greyhawk area had copied Midgaard and left in that piece of eq when they redid it. I guess I will just delete them.

Interesting what things start tangents in these threads (and for that matter what things are
totally ignored), oh well, I suppose that is just the nature of the beast.

Anyway, I was just wondering if editing the area file fixed the problem or not.

Yes it did fix the problem (from what I've seen so far). I'm going to test it a bit more before I compile my player port.

And just as I was about to tell him his best route was to ditch Linux and GCC and instead use Windows and VC++…

Seriously though, DikuMud problems are best solved in this order…
1: I suck
2: Diku sucks
3: goto 1
4: my compiler sucks
5: my operating system sucks