6. Some Solutions to Common Problems

This section provides some answers to some common problems and questions. Please send me mail with any additions to this list - either problems you are still having or tips that you would like to pass on.

When diagnosing a problem, if possible, always make sure you are running the most up to date version of Dmalloc available from the home page at URL http://dmalloc.com/. Problems are often fixed and a new release can be published before people encounter them.

`Why does my program run so slow?'

This library has never been (and maybe never will be) optimized for space nor speed. Some of its features make it unable to use some of the organizational methods of other more efficient heap libraries.

If you have the check-heap token enabled, your program might run slow or seem to hang. This is because by default, the library will run a full check of the heap with every memory allocation or free. You can have the library check itself less frequently by using the -i option to the dmalloc utility. See section Dmalloc Utility Program. If you are using the high token and you need your program to run faster, try the medium or low tokens which don't check as many heap features and so run faster although they will not catch as many problems. See section Format of the Runtime Configuration File.

`Why was a log-file not produced after I ran my program?'

This could be caused by a number of different problems.

1. Are you sure you followed all of the items in the "Getting Started" section? Please review them if there is any doubt. See section Getting Started with the Library.
2. Use the env or printenv commands to make sure that the `DMALLOC_OPTIONS' variable is set in your exported environment. See section Environment Variable Name and Features.
3. Make sure that your program has been compiled correctly with the dmalloc library. The ident program should show chunk.c and other dmalloc files compiled into your program. You can also do strings -a your-program | grep chunk.c and look for something like `$Id: chunk.c,v 1.152 1999/08/25 12:37:01 gray Exp $' with different versions and date information. If this doesn't show up then chances are dmalloc was not linked into your program.
4. If your program changes its working directory, it may write the dmalloc log-file somewhere else in the filesystem. You will need to check both where the program was started and to where it might change directory.
5. The logfile is only produced when dmalloc_shutdown() is called. By default it will be called when exit() gets called. If you are running your program and press Control-C under Unix the program will stop immediately and dmalloc_shutdown() will not get called. You can either setup a signal handler for SIGINTR and call exit yourself, or you can enable the catch-signals token. See section Description of the Debugging Tokens.
6. If your program is segfaulting or otherwise crashing when it exits, the exit() routine may not being called. You will have to resolve these issues so the dmalloc library can gracefully exit and write its log file.
7. You may want to call dmalloc_log_stats() and dmalloc_log_unfreed() (or dmalloc_log_changed()) directly to have the library write its log file. Some system modules may not have shutdown if you call this before exit() so extra unfreed memory may be reported.

`I don't see any information about my non-freed (leaked) memory?'

The library will not (by default) report on "unknown" non-freed memory. Unknown means memory that does not have associated file and line information.

This will be necessary if you are not including `dmalloc.h' in all of your C files or if you are interested in tracking leaks in system functions.

`Dmalloc is returning the error "malloc library has gone recursive"'

This most likely indicates that you are using the Dmalloc library within a threaded application and two threads are trying to use the dmalloc library at once. Please see the section of the manual about threads for more information about properly configuring the library. See section Using the Library with a Thread Package.

If you are not using threads, then your program could have caught a signal while within Dmalloc, which then in turn called a memory allocation routine. It is unwise to allocate memory on the heap in most signal handlers. Lastly, some functions called by the library may call memory routines that it does not anticipate. If you think this the case, please report the problem and include a stack trace, operating system version/type, and the version of Dmalloc you are using.

This document was generated by Gray Watson on May, 16 2007 using texi2html 1.76.

This work is licensed by Gray Watson under the Creative Commons Attribution-Share Alike 3.0 License.
This page should be W3C Valid XHTML and should work with most browsers.