If I remember correctly, capitalize uses a static char variable, unless
you've modified yours... this is the reason you can't do multiple calls
to capitalize within the same sprintf, for example, or else all calls to
it will show up as the same value during output, whatever the last call
happened to store in it, example:

sprintf(buf,"You are a %s %s\n\r",
capitalize(race_table[ch->race].name),
capitalize(class_table[ch->class].name));

would actually output something like this:

You are a Mage Mage.

Because when the 2nd call is made, it overwrites the value in the static
buffer, and sprintf evaluates the terms after all values have been
evaluated... being that it uses a static char variable, it shouldn't be
allocating on every call, but if you've modified yours to do say:

return str_dup(buf);

at the end of the function, instead of returning the address of the
static variable, then it would allocate a new space, and in order to
free that you'd want to do something like:

char *race, *class;

race = capitalize(race_table[ch->race].name);
class = capitalize(class_table[ch->race].class);
sprintf("You are a %s %s.\n\r", race, class);
free_string(race);
free_string(class);

I believe that's correct, but as I'm not a memory guru, I'm sure there
are holes in it that someone else can point out :D

Richard Lindsey.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Valnir
Sent: Wednesday, April 06, 2005 9:06 AM
To: [email protected]
Subject: Re: Memory issues.

Ok.. first off, thanks for the toys.. Splint is nice.

Secondly.. it is telling me that I have memory leaks in a couple of 
functions that send a string (char) to another function to return it 
modified. For example:

act_comm.c:108:48: New fresh storage (type char *) passed as implicitly
temp
                      (not released): capitalize(ch->name)
  A memory leak has been detected. Storage allocated locally is not
released
  before the last reference to it is lost. (Use -mustfreefresh to
inhibit
  warning)

Thoughts on how to fix these errors?

- Valnir

----- Original Message ----- 
From: "Christopher Bunting" <[EMAIL PROTECTED]>
To: "Valnir" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Wednesday, April 06, 2005 6:58 AM
Subject: Re: Memory issues.


> Hello,
>
> Were you the one who issued the mstat command? If someone creates a
> mob using OLC or adds a mobprog that isn't coded correctly,  Issuing
> the mstat command will cause the mud to crash.
>
>>>Lastly, does anyone know of a way to find memory leaks?
>
> Are you running on linux? If you, you should download GNU Lint and
> also read the docs.. Lint will give you a ton of more infomation about
> your mud over GDB. Lint will also tell you if sytax is wrong or
> various other possibile warnings in your code that GDB won't or may
> not catch. I rarely hear mention of this I guess since most people
> rely on what is most popular or well known.. But read up on lint.. I
> personally think it's great.
>
> Links to great tools for Mud Developers.. The first 3 tools are for
> Linux, The last one, API Monitor is for Windows.. A good program for
> those using windows/mysql and Rom.
>
> Valgrind:
> The distribution currently includes five tools: two memory error
> detectors, a thread error detector, a cache profiler and a heap
> profiler.
> http://valgrind.org/
>
> Slint:
> Splint is a tool for statically checking C programs for security
> vulnerabilities and coding mistakes.
> http://www.splint.org/
>
> Data Display Debugger:
> DDD is a graphical front-end for command-line debuggers such as GDB,
> DBX, WDB, Ladebug, JDB, XDB, the Perl debugger, the bash debugger, or
> the Python debugger. DDD displays data structures as graphs and plots.
> http://sourceforge.net/projects/ddd/
>
> API Monitor for Windows Users:
> API Monitor is a software that monitors and displays API calls made by
> applications. Its a powerful tool for seeing how Windows and other
> applications work or tracking down problems that you have in your own
> applications.
> http://www.rohitab.com/apimonitor/
>
> Hope this helps,
> Chris
> 


-- 
ROM mailing list
[email protected]
Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom

Reply via email to