Re: gEDA-user: Small patch to aid use of lib dmalloc

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Mon, 2010-12-06 at 16:58 +1100, Stephen Ecob wrote:
> If you use (or intend to use) lib dmalloc with PCB you will find the
> following useful.
> 
> I've uploaded a patch against current heaad to sourceforge, ID
> #3129279, described as follows:

Looks useful, I will push it, however, please explain the following first:

+#  define MyCalloc(a, b, c) calloc((a) ? (a) : 1, (b) ? (b) : 1)
+#  define MyMalloc(a, b) malloc((a) ? (a) : 1)
+#  define MyRealloc(a, b, c) ((a) ? realloc(a, (b) ? (b) : 1) : malloc((b) ? (b) : 1))

I don't see why we are adding a synonym with requesting zero bytes /
zero items, with requesting one item?

Is there anywhere (BROKEN) in PCB which requests zero items / bytes, and
expects that call to work?

I'd rather commit:

+#  define MyCalloc(a, b, c) calloc((a), (b))
+#  define MyMalloc(a, b) malloc((a))
+#  define MyRealloc(a, b, c) realloc((a), (b))

NB: realloc will "do the right thing" if the previous pointer passed is
NULL, no need to check and swap for a malloc call.

One final nit, I'd prefer not to see the double negative in the header
files:

#ifndef HAVE_LIBDMALLOC
....NON D-Malloc stuff
#else
....D-Malloc stuff
#endif


Could more readably be defined as:

#ifdef HAVE_LIBDMALLOC
....D-Malloc stuff
#else
....NON D-Malloc stuff
#endif


If you feel that your version is better as it matches the various other
#ifndef HAVE_LIBDMALLOC you added, then fair enough, I'll push as is
pending an answer on the #define questions.


FWIW, I'd love to see our own custom memory allocation routines die in a
fire. Lets plan to eventually replace them with malloc / realloc / free
calls, and this won't be an issue.

I did loose some respect for the dmalloc author(s) when I noticed on
their page they can't spell "Microsoft Windows" correctly. "Windoze"

In general, valgrind (probably not even conceived of when dmalloc was
first written), is a much more useful tool for memory leak diagnosis, so
I wouldn't go _too_ far out of our way to make things dmalloc suitable.

You still won't see good back-traces for the r_tree allocations, for
example. (Given your usage and symptoms, I guess some r_trees are being
leaked in the autorouter code?)

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user