[bugzilla-daemon@xxxxxxxxxxxxx]

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.