Ya currently working with my sys admin to get Dmalloc up and working for me. It's probly all I need to track this 14k mem leack that happens when you log in.
----- Original Message ----- From: "Bobby Bailey" <[EMAIL PROTECTED]> To: "Dale Kingston" <[EMAIL PROTECTED]> Sent: Tuesday, December 03, 2002 11:26 AM Subject: Re: Memory Leaks On Sunday 01 December 2002 12:33 am, you wrote: > Thanks, this tool will be nice for some of the newer things I'm writing. But > the mem leack I'm trying to located I don't think uses any of the new C++. > Cause I noticed it with the mem command. With my number the perms, somewhere > when logging in and then out and then when I come back in the mud has 14084 > more bytes of memory. So I'm pretty sure thats something thats running > though alloc_perm. Know of any tools that will track malloc, or calloc? Electric fence can help with tracking down memory corruption. It basically works by inserted a locked memory page after every page of memory the mud allocates, to where it can detect any attempts to read, write, or otherwise access memory at invalid addresses. Very handy for tracking things down like overwriting the ends of arrays and things like that. The end result is you have an exectuable that will immediately drop core at the precise instruction that tried to read/write/access invalid memory, so gdb becomes actually useful, letting you pinpoint the bad code, rather than trying to diagnose it after memory gets trashed and your stack goes all to hell. For tracking likes like alloc_perm, it's a bit harder. Whenever more memory is needed, alloc_perm grabs it and allocates it. It doesn't always lead to corrupted memory though. Like let's say in your who command it allocated space for a new CHAR_DATA, and didn't free it. It's a memory leak for sure because you lose the pointer when the function exits, but tools like electric fence won't always find it because the memory is still valid, there's just no more references pointing to it in the code. The memory pools that Diku and derivatives keep around using alloc_perm and such is part of why it's harder to use proper memory analysis tools. If everything were allocated and freed immediately, memory leaks would be a snap to track down. :) Anyway, for tools, I've used ElectricFence, and for pure C code a decent Lint-like program is a good way to track things down. I use splint (http://www.splint.org/) as my C linter.. works pretty well, and can help track down a lot of problems, including memory leaks from allocating memory in a function and then losing all references to it by not freeing it or storing the variable somewhere before the function exits. I haven't used it personally, but I've heard good things about the dmalloc library, which is installed on just about every linux distribution there is, and possibly on other *nix systems as well. It provides boatloads of statistics and memory checking for malloc/realloc/calloc/etc, just by adding the -ldmalloc lib to your executable and setting some environment variables. Neat stuff, or so I've heard. Its homepage is over at http://dmalloc.com. I haven't personally used LeakTracer, so I'm afraid I won't be of much help there. -- Bobby Bailey | "The only source of knowledge is experience." MUD Developer | -- Albert Einstein Internet Junkie | PGP Keys: http://chil.kyndig.com/pgp http://www.kyndig.com/ -- Mud & Online Text Game Community
