I was trying to add some areas, I put the area file in my area dir and added it to the area.lst, When I restart the mud I get a Bug MAX_STRING_LENGTH error. The strange part is if I take an old area out and add that same new area everything works fine. I seem to have to take and area out to add an area. If I create a new area with OLC I have no issues, but if I edit that new OLC area I get the same BUg MAX_STRING_LENGHT error. I am using ROM2.4b6 with OLC. Any ideas on how to fix this?

Could be a vnum number overlap. Could be a problem in the area list.
Not enough info, use gdb and wait the crash moment to understand why it is triggered. Should be pretty easy to understand since you can reproduce it at ill.

This is the Error I get:
Wed Aug 5 21:57:43 2015 :: [*****] FILE: tohell.are LINE: 243
Wed Aug 5 21:57:43 2015 :: [*****] BUG: Fread_string: MAX_STRING 1413120 exceeded.

If I run GDB I get this:
Wed Aug 5 22:11:29 2015 :: [*****] FILE: tohell.are LINE: 243
Wed Aug 5 22:11:29 2015 :: [*****] BUG: Fread_string: MAX_STRING 1413120 exceeded.
[Inferior 1 (process 21910) exited with code 01]


If I take out my New area I added everything starts up fine, If I leave new area and take this one or any other area out everything starts up file. I verified VNUMS and didn't see anything conflicting.

Snippet from tohell.are (Stock area nothing changed)
#10416
oldstyle bloody severed nose~
bloody severed nose~
A bloody severed nose lies here.
~[Inferior 1 (process 21858) exited with code 01]
I wonder how the person that lost this smells…Hopefully not as bad as
this nose does…
~ **** THIS IS LINE 243 ****
human~
AB J -800 0
33 0 10d10+1100 16d9+100 6d4+10 none
-11 -11 -11 5
EFNU 0 0 0
stand stand none 5000
AHMV ABCDEFGHIJK medium unknown

Debugging is usually an exercise in excruciating detail, doubly so when you're trying to do it through a forum or email. A bug relating to MAX_STRING is a very different beast from a bug about MAX_STRING_LENGTH. You really have to nail details like that when you're asking for help.

So when starting up, stock ROM preallocates a block of MAX_STRING bytes (about 1.34 MB) for allocating certain strings read from your area files. Your game is telling you that 1.34MB is no longer big enough for your purposes, either because you have a lot of areas or they're very verbose. Find this line in db.c and double or quadruple the number.

#define                 MAX_STRING      1413120

Some day your new number may be too small again, but unless you're installing every area file you can find online it should last you for quite a while.

That fixed my Issue, Thanks. I knew it had to be something simple like that.

I doubt it is as simple, it may just hide a bug under the carpet. You still do not know WHY the string was too small, and that is a problem in itself.

that IS the issue… ive come across this numerous times… :)

That limited ? Heh, I did not even found an occurence of this one in my code. Only using max_str_length but I rewrited pretty much everything memory related that may be why :)

MAX_STRING is different read what Pymeus posted.. the above error really only occurs when your mud has a lot of areas…

That is what I am saying: even if my mud is rom based, this constant totally disappeared from my code (and thus from everywhere it was used)
I pretty much rewrote everything memory related.

It's 2015, and this is still the primary allocation mechanism for strings? And 1.4 megabytes of string space is considered "a lot" of areas? And the community wonders why muds aren't more popular?

Back in 1996 1.4 megabytes was a lot of memory! - The problem is these releases haven't been updated really since then! So new people wanting to run MUDs are downloading the stock versions which are on this site!

Someone could update the releases so they use current standards.. but again this takes time, something that most people who are running muds, want to spend on their own creations. I know there was a Rom implementation based on Python being discussed on here a while back… but even that seems to have slowed…

Behold! DikuMud in 1991. Problem is that reworking the memory system while retaining the memory tracking that it does is a non-trivial task and doesn't actually buy you much except not having to increase MAX_STRING every few months (and the ability to use Valgrind and other similar tools effectively), and so it's been kept around in each derivitive. If someone came up with a generic patch, or even a series of patches to popular codebases, I'm sure it'd be very popular.

This is why continuing to suffer with a C codebase is silly. Nobody codes like this anymore, it's not worth the effort you have to put into debugging and management to even maintain this nonsense anymore.

Do yourself a favor. Take a year (less if you can devote real time to it) and rewrite your MUD in any semi-modern language. Python, Perl, Ruby, C#, even Java…. It will seriously take you less effort, and you'll learn exactly how every part of your game works in the process of rewriting it.

While C is a fairly poor choice for writing a mud, it's not the entire problem here. The problem is people keep going back to a codebase that hasn't been maintained for about 21 years now as a starting point for new games. If you just like ROM's way of doing things, it has many offspring that fixed its limitations long ago, at least one of which is not written in C.


They do actually. This is a simple variation on an Arena Allocator. You'll see those used in high-performance graphics code (ie 3D game rendering), scientific computing, and possibly embedded systems. I'm sure they have applications in OS kernels. This forum's Apache webserver uses them, and allegedly Postgresql does too.

I wish arenas were available in more semi-modern languages. They are even more appropriate for modern hardware and GC'd languages than they were in ROM's heyday.

+1, insightful. And yet, I don't think any derivative – I will hopefully stand corrected in future posts – actually went back and re-did the memory allocator. The problems being that a) it is scary code for a newer programmer, such as those that might be getting into muds, to look at; and b) it actually provides a useful service in the way of object/string/mob/room/affect/etc. counting that is non-trivial to replace, and provides no tangible user benefit when it is.



I recently worked with an embedded system where malloc() returned one of two 4MB blocks, and blocked if neither had been released yet, so up-front static allocation was preferred. But that's just one project. Embedded is weird, and frequently has requirements that make seasoned engineers screw their faces up in resigned disgust.

I'd like to just point out that Rom is the one that added their own funky memory manager to try and save space. An admiral goal back in the days when 4MB was a LOT of memory, and the system malloc() was horribly slow. I don't think DikuMUD did any such thing. At least, I know my own game doesn't, and it started out as DikuMUD Alfa.

My code just has ugly macros like this:

#define CREATE(result, type, number)                                    \
do                                                                      \
{                                                                       \
  if (!((result) = (type *) calloc ((number), sizeof(type))))           \
  {                                                                     \
    perror("calloc failure");                                           \
    fprintf(stderr, "Calloc failure @ %s:%d\n", __FILE__, __LINE__ );   \
    fflush(stderr);                                                     \
    proper_exit(42);                                                    \
  }                                                                     \
} while(0)

#define DESTROY(point)                                                  \
do                                                                      \
{                                                                       \
  if((point))                                                           \
  {                                                                     \
    free((point));                                                      \
    (point) = NULL;                                                     \
  }                                                                     \
} while(0)

Most of the memory stuff isn't that bad, really, just needs adjustments here and there.

For example, you could replace MAX_STRING with a variable, store it across reboots, and always size string_space with a safety margin on top of that value at reboot/copyover. When you exceed MAX_STRING, you can fall back to malloc() and just accept that you're using a lot more memory than usual until the next reboot/copyover. We do both of these, more or less.

There is actually a snippet out there that does just that. Not sure if its on mudbytes or not, haven't looked for one in years. But I suspect it would be here.

I know mkwSys included something like that, although it seems to have been largely scoured from the face of the web. The only copy of it I can find is here in the Internet Wayback Machine.