User Name:


Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, Yandex, dbnu, DotBot, Google

Members: 1
Guests: 4
Newest Member
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SmaugFUSS » [BUG] Polymorph Code
Forum Rules | Mark all | Recent Posts

[BUG] Polymorph Code
< Newer Topic :: Older Topic > morph->help pointer

Pages:<< prev 1 next >>
Post is unread #1 May 8, 2003, 10:08 am
Go to the top of the page
Go to the bottom of the page

Black Hand
JoinedJan 1, 2002

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[0] )
           STRFREE( morph->help );
           morph->help = STRALLOC( arg3 );

But then notice here, in fread_morph:

case 'H':
 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. :)
Pages:<< prev 1 next >>