ram-smalloc.c

/*
 * $Id: ram-smalloc.c,v 0.30 1999/05/24 09:34:35 ceder Exp $
 * Copyright (C) 1991-1996, 1998-1999  Lysator Academic Computer Association.
 *
 * This file is part of the LysKOM server.
 * 
 * LysKOM is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published by 
 * the Free Software Foundation; either version 1, or (at your option) 
 * any later version.
 * 
 * LysKOM is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with LysKOM; see the file COPYING.  If not, write to
 * Lysator, c/o ISY, Linkoping University, S-581 83 Linkoping, SWEDEN,
 * or the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, 
 * MA 02139, USA.
 *
 * Please mail bug reports to bug-lyskom@lysator.liu.se. 
 */
/*
 * smalloc.c
 *
 * Contains memory allocator routines
 *
 *	TEST VERSION by ceder
 */


#ifdef HAVE_CONFIG_H
#  include <config.h>
#endif

/*
 * Finding memory leaks
 * ====================
 *
 * This code contains some stubs that can be useful when hunting for
 * memory leaks.  To use it, you must configure with
 * --with-traced-allocations and recompile. You actually only need to
 * recompile ram-smalloc.c, ramkomd.c and the programs in testsuite
 * after changing it, so "make -t; rm src/server/ram-smalloc.o \
 * src/server/ramkomd.o src/server/testsuite/test-*.o; make" is the 
 * fastest way to change between tracing and a normal compile.
 *
 * Run the resulting lyskomd under gdb, like this:
 *            bash$ gdb lyskomd
 *            (gdb) source trace-mem.gdb
 *            (gdb) run
 *            Where does the trace want to go today? [stderr] RET
 * gdb will print a backtrace and continue whenever memory is
 * allocated, reallocated or released.  The program itself will also
 * print out some information.  The result is a long log file.
 *
 * Run M-x resolve-trace (from handle-malloc-dump.el on the resulting
 * output.  Look in the *Result* buffer for the result.
 *
 * Using the test suite to find memory leaks
 * =========================================
 *
 * This code can also be used together with the test suite, even
 * though that is slightly more complicated.  Begin by starting a gdb
 * whose output is saved, for example by running it in a shell buffer
 * in emacs (note: do not use M-x gdb -- that will slow down the
 * process and it is slow enough as it is):
 *            bash$ gdb lyskomd