Discovered another one while auditing string allocation today. The MORPH_DATA pointer for morph->help is being handled incorrectly by copy_buffer.
Note here, in do_morphset:
STRFREE( morph->help );
morph->help = copy_buffer( ch );
And again here, further down in do_morphset:
if ( arg3 )
STRFREE( morph->help );
morph->help = STRALLOC( arg3 );
But then notice here, in fread_morph:
MKEY( "Help", morph->help, fread_string_nohash(fp));
The fread_morph function is expecting this to be a NON-hashed string, yet copy_buffer and do_morphset are expecting this to be a hashed string. See the problem yet? Lets continue....
Further down, we come to this gem in free_morph:
if ( morph->help )
DISPOSE ( morph->help );
Again, the code is expecting this to be NON-hashed.
morph->help = str_dup ( "" );
Once more.... yes. I'm sure you're seeing the nigthmare problem now aren't you!
But it gets better!
morph->help = str_dup ( temp->help );
ARGH! Will it never end?!?!?
Well, yes. It does, but as I'm sure you can see, the damage has been done. What a train wreck.
Now, this isn't an easy fix, and quite frankly I'm not sure why this nasty scenario hasn't caused problems in the past, though perhaps it has and we've just not seen it yet. Could be an explanation for many odd bugs since STRFREE'ing a str_dup'd pointer is a BAD BAD thing to do. So is DISPOSE'ing something the code originally STRALLOC'd. Could also be that not many people bother with making morph->help entries. The problem of course comes from how the hell do you fix this easily. Well, you don't. Had this not used copy_buffer it would have been trivial, but it DOES and we're stuck with that.
Ok, so I lied. The easy fix is to turn all instances of morph->help into hashed strings, which will solve the problem - except that it wastes hash space. If you don't care about wasting hash space ( and not many people do apparently ) then the easy fix is to go back over the code samples and change any DISPOSE to STRFREE, any fread_string_nohash to fread_string, any str_dup to a STRALLOC and you'll be bug free after compiling.
This bug affects all versions of Smaug from 1.4 and up, and all derivatives based upon that. If you're not sure if it affects you, check to see if you have polymorph.c, which will be labeled as "Shaddai's Polymorph" in the code headers.
For AFKMud users - a patch will be forthcoming that will address this AND the hash wastage by introducing the copy_buffer_nohash code that was proposed some time ago on the SML. Give me time to test it and it will be posted on the AFKMud webpage.
FUSS will be updated with the cheap fix soon.