Okay, I'm quite new to AFKMud, so this is probably a very newbish question.
I've managed to get AFKMud (2.0) to compile through cygwin, after a bit of trouble with libgd. However, gets an error whenever I go to run it. The output looks something like this:

Any ideas on what's gone wrong? I've noticed that 3620 tends to change every time I attempt to run it, incase that's meaningful.

By the way, I have very little experience with C++ (although I have had experience with a few other languages), and I also have smaugfuss working on this computer, if all else fails, I'll just go back to it.

You could try checking out the gdb backtrace, but if your stack is corrupted that won't be terribly helpful. If indeed the stack is corrupted, the best way to find that is by using valgrind. I'm not sure if valgrind is available for Cygwin, though...

It would be helpful to see the entire backtrace on this. What you've shown us is only enough to speculate that perhaps the Cygwin installation itself isn't quite right, since Frame 0 indicates a fault in the cygwin1.dll file.

Valgrind is also not supported on Cygwin so that option isn't available.

All I had done was compile and run. I tried cleaning, but that made no difference.
I do have a linux box, although its a fairly clean install, and I don't think it has the right packages. Would compiling through it be my best bet now?

Valgrind is a tool meant to find this kind of problem; gdb is meant to find other kinds of problems. (It doesn't detect stack corruption.)

So trying this on a Linux box is definitely a good idea if you can. If you are running a Debian-based system, you should do (as root): aptitude install valgrind. If you have a Fedora system, I believe the command is (again as root): yum install valgrind. If you have another system, you'll have to do whatever you normally do to install packages.

Once you have valgrind, you run the program like so: go to the area directory, then type: valgrind ../src/smaug. Adjust the executable name as necessary, and optionally add the port number in case you're not using the default.

Once you have it running in valgrind, do whatever you do to get the crash. Valgrind should tell you exactly where the stack gets corrupted. You'll have to read its output and go from there.

Okay, I'm quite new to AFKMud, so this is probably a very newbish question.
I've managed to get AFKMud (2.0) to compile through cygwin, after a bit of trouble with libgd. However, gets an error whenever I go to run it. The output looks something like this:
Code:

Any ideas on what's gone wrong? I've noticed that 3620 tends to change every time I attempt to run it, incase that's meaningful.

By the way, I have very little experience with C++ (although I have had experience with a few other languages), and I also have smaugfuss working on this computer, if all else fails, I'll just go back to it.

Something that strikes me as odd is you did ../area/afkmud.exe when the afkmud.exe file should be in the src directory (at least it was in my test). Also the shops directory was empty on a stock release so had no crashing issue caused by this issue.

I would guess that this issue is caused from fread_mobile setting things that are already set. It was fixed in a higher version of AFKMud (I checked 2.03 and it's fixed in it). Try making your fread_mobile in save.cpp looking like the one in 2.03 and see if that fixes the issue.

Something that strikes me as odd is you did ../area/afkmud.exe when the afkmud.exe file should be in the src directory (at least it was in my test). Also the shops directory was empty on a stock release so had no crashing issue caused by this issue.

That was a typo on my behalf...I have been running afkmud.exe (which is in the src directory) from the area directory.
And as I wasn't sure whether you wanted me to compile the same sources on my linux box, I'll just try compiling and running a clean version of 2.03
EDIT: Works fine on linux. Yet to decide whether I'll use it permanently

It would be best to copy your entire directory over to Linux, recompile, and run that. If the exact same files work on Linux, then this is a problem with Cygwin. (Not sure how Cygwin would be causing a stack overflow, though...)