Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Back: Interpreting Commands from a File
Forward: M4
 
FastBack: A Complex GNU Autotools Project
Up: A Complex GNU Autotools Project
FastForward: M4
Top: Autoconf, Automake, and Libtool
Contents: Table of Contents
Index: Index
About: About this document

20.4 Integrating Dmalloc

A huge number of bugs in C and C++ code are caused by mismanagement of memory. Using the wrapper functions described earlier (see section 9.2.1.2 Memory Management), or their equivalent, can help immensely in reducing the occurrence of such bugs. Ultimately, you will introduce a difficult-to-diagnose memory bug in spite of these measures.

That is where Dmalloc(48) comes in. I recommend using it routinely in all of your projects -- you will find all sorts of leaks and bugs that might otherwise have lain dormant for some time. Automake has explicit support for Dmalloc to make using it in your own projects as painless as possible. The first step is to add the macro `AM_WITH_DMALLOC' to `configure.in'. Citing this macro adds a `--with-dmalloc' option to configure, which, when specified by the user, adds `-ldmalloc' to `LIBS' and defines `WITH_DMALLOC'.

The usefulness of Dmalloc is much increased by compiling an entire project with the header, `dmalloc.h' -- easily achieved in Sic by conditionally adding it to `common-h.in':

 
BEGIN_C_DECLS

#define XCALLOC(type, num)                                      \
        ((type *) xcalloc ((num), sizeof(type)))
#define XMALLOC(type, num)                                      \
        ((type *) xmalloc ((num) * sizeof(type)))
#define XREALLOC(type, p, num)                                  \
        ((type *) xrealloc ((p), (num) * sizeof(type)))
#define XFREE(stale)                    do {                    \
        if (stale) { free ((void *) stale);  stale = 0; }       \
                                        } while (0)

extern void *xcalloc          (size_t num, size_t size);
extern void *xmalloc          (size_t num);
extern void *xrealloc         (void *p, size_t num);
extern char *xstrdup          (const char *string);

END_C_DECLS

#if WITH_DMALLOC
#  include <dmalloc.h>
#endif

I have been careful to include the `dmalloc.h' header from the end of this file so that it overrides my own definitions without renaming the function prototypes. Similarly I must be careful to accommodate Dmalloc's redefinition of the mallocation routines in `sic/xmalloc.c' and `sic/xstrdup.c', by putting each file inside an `#ifndef WITH_DMALLOC'. That way, when compiling the project, if `--with-dmalloc' is specified and the `WITH_DMALLOC' preprocessor symbol is defined, then Dmalloc's debugging definitions of xstrdup et. al. will be used in place of the versions I wrote.

Enabling Dmalloc is now simply a matter of reconfiguring the whole package using the `--with-dmalloc' option, and disabling it again is a matter of reconfiguring without that option.

The use of Dmalloc is beyond the scope of this book, and is in any case described very well in the documentation that comes with the package. I strongly recommend you become familiar with it -- the time you invest here will pay dividends many times over in the time you save debugging.

This chapter completes the description of the Sic library project, and indeed this part of the book. All of the infrastructure for building an advanced command line shell is in place now -- you need only add the builtin and syntax function definitions to create a complete shell of your own.

Each of the chapters in the next part of the book explores a more specialised application of the GNU Autotools, starting with a discussion of M4, a major part of the implementation of Autoconf.


This document was generated by Gary V. Vaughan on February, 8 2006 using texi2html

 
 
  Published under the terms of the Open Publication License Design by Interspire