https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5821
--- Comment #2 from Guy Harris <guy@xxxxxxxxxxxx> 2011-04-12 19:25:29 PDT ---
Yes, the memory-use-tracking stuff would be useful and, yes, cranking up the
debugging level for malloc - on any platforms that let you do that - would be
useful. You can crank the malloc debugging up another notch with the "guard
malloc" library:
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/libgmalloc.3.html
although, as the man page notes:
libgmalloc doesn't come without some weaknesses. First, because each
allocation requires two pages of
virtual memory, only about 500,000 malloc allocations could conceivably exist
before you run out of
virtual memory. The extravagant use of virtual memory will also cause much
more swapping, so the pro-
gram will run much slower than usual -- usually two orders of magnitude
(100x).
The Linux malloc man page at
http://www.kernel.org/doc/man-pages/online/pages/man3/malloc.3.html
says:
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
include a
malloc() implementation which is tunable via environment variables.
When
MALLOC_CHECK_ is set, a special (less efficient) implementation is used
which
is designed to be tolerant against simple errors, such as double calls
of
free() with the same argument, or overruns of a single byte (off-by-one
bugs).
Not all such errors can be protected against, however, and memory leaks
can
result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is
silently ignored; if set to 1, a diagnostic message is printed on
stderr; if
set to 2, abort(3) is called immediately; if set to 3, a diagnostic
message is
printed on stderr and the program is aborted. Using a nonzero
MALLOC_CHECK_
value can be useful because otherwise a crash may happen much later, and
the
true cause for the problem is then very hard to track down.
and the FreeBSD 8.2 malloc man page at
http://www.FreeBSD.org/cgi/man.cgi?query=malloc&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&format=html
says:
Once, when the first call is made to one of these memory allocation rou-
tines, various flags will be set or reset, which affects the workings of
this allocator implementation.
The ``name'' of the file referenced by the symbolic link named
/etc/malloc.conf, the value of the environment variable MALLOC_OPTIONS,
and the string pointed to by the global variable _malloc_options will be
interpreted, in that order, from left to right as flags.
Each flag is a single letter, optionally prefixed by a non-negative base
10 integer repetition count. For example, ``3N'' is equivalent to
``NNN''. Some flags control parameter magnitudes, where uppercase
increases the magnitude, and lowercase decreases the magnitude. Other
flags control boolean parameters, where uppercase indicates that a behav-
ior is set, or on, and lowercase means that a behavior is not set, or
off.
...
J Each byte of new memory allocated by malloc(), realloc() or
reallocf() will be initialized to 0xa5. All memory returned
by
free(), realloc() or reallocf() will be initialized to 0x5a.
This is intended for debugging and will impact performance
nega-
tively.
...
ENVIRONMENT
The following environment variables affect the execution of the alloca-
tion functions:
MALLOC_OPTIONS If the environment variable MALLOC_OPTIONS is set, the
characters it contains will be interpreted as flags to
the allocation functions.
and the NetBSD 5.0 man page and OpenBSD 4.8 manpage are similar.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
