watchmalloc man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]


       watchmalloc - debugging memory allocator

       #include <stdlib.h>

       void *malloc(size_t size);

       void free(void *ptr);

       void *realloc(void *ptr, size_t size);

       void *memalign(size_t alignment, size_t size);

       void *valloc(size_t size);

       void *calloc(size_t nelem, size_t elsize);

       #include <malloc.h>

       int mallopt(int cmd, int value);

       struct mallinfo mallinfo(void);

       The  collection	of  malloc()  functions	 in  this shared object are an
       optional replacement for the standard versions of the  same   functions
       in  the	system	C  library. See malloc(3C). They provide a more strict
       interface than the standard versions  and  enable  enforcement  of  the
       interface through the watchpoint facility of /proc. See proc(4).

       Any  dynamically	 linked application can be run with these functions in
       place of the standard functions if the following string is  present  in
       the environment (see

       The  individual	function interfaces are identical to the standard ones
       as described in malloc(3C). However, laxities provided in the  standard
       versions are not permitted when the watchpoint facility is enabled (see
       WATCHPOINTS  below):

	   o	  Memory may not be freed more than once.

	   o	  A pointer to freed memory may not be used in a call to real‐

	   o	  A  call  to  malloc() immediately following a call to free()
		  will not return the same space.

	   o	  Any reference to memory that has been freed yields undefined

       To enforce these restrictions partially, without great loss in speed as
       compared to the watchpoint facility described below, a freed  block  of
       memory is overwritten with the pattern 0xdeadbeef before returning from
       free(). The malloc() function returns with the allocated memory	filled
       with the pattern 0xbaddcafe as a precaution against applications incor‐
       rectly expecting to  receive  back  unmodified  memory  from  the  last
       free().	The  calloc()  function	 always	 returns with the memory zero-

       Entry points for mallopt() and mallinfo() are provided  as  empty  rou‐
       tines,  and are present only because some malloc() implementations pro‐
       vide them.

       The watchpoint facility of /proc can be applied by a process to itself.
       The  functions  in  use this feature if the following
       string is present in the environment:


       This causes every block of freed memory to  be  covered	with  WA_WRITE
       watched	areas.	If the application attempts to write any part of freed
       memory, it will trigger a watchpoint trap, resulting in a SIGTRAP  sig‐
       nal, which normally produces an	application core dump.

       A  header  is  maintained  before  each block of allocated memory. Each
       header is covered with a watched area, thereby  providing  a  red  zone
       before  and  after  each	 block of allocated memory (the header for the
       subsequent memory block serves as the trailing red zone for its preced‐
       ing  memory  block).  Writing  just before or just after a memory block
       returned by malloc() will trigger a watchpoint trap.

       Watchpoints  incur  a  large  performance  penalty.   Requesting	  MAL‐
       LOC_DEBUG=WATCH	can  cause  the	 application  to  run  10 to 100 times
       slower, depending on the use made of allocated memory.

       Further options are enabled by specifying a comma-separated  string  of


		Enables WA_WRITE watched areas as described above.

		Enables	 both  WA_READ	and WA_WRITE watched areas. An attempt
		either to read or write freed memory or	 the  red  zones  will
		trigger a watchpoint trap.  This incurs even more overhead and
		can cause the application to run up to 1000 times slower.

		The process will stop showing a FLTWATCH machine fault	if  it
		triggers  a  watchpoint	 trap, rather than dumping core with a
		SIGTRAP signal. This allows a debugger to be attached  to  the
		live  process  at  the point where it underwent the watchpoint
		trap. Also, the various /proc tools described in  proc(1)  can
		be used to examine the stopped process.

       One  of	WATCH or RW must be specified, else the watchpoint facility is
       not engaged. RW overrides  WATCH.  Unrecognized	options	 are  silently

       Sizes  of  memory  blocks  allocated  by malloc() are rounded up to the
       worst-case alignment size, 8 bytes for 32-bit processes	and  16	 bytes
       for  64-bit processes. Accessing the extra space allocated for a memory
       block is technically a memory violation but is in fact innocuous.  Such
       accesses are not detected by the watchpoint facility of watchmalloc.

       Interposition  of  fails  innocuously	if  the target
       application is statically linked with respect  to  its  malloc()	 func‐

       See attributes(5) for descriptions of the following attributes:

       │MT-Level       │ MT-Safe	 │

       proc(1),	 bsdmalloc(3MALLOC),  calloc(3C),  free(3C),  malloc(3C), mal‐
       loc(3MALLOC),  mapmalloc(3MALLOC),  memalign(3C),   realloc(3C),	  val‐
       loc(3C), libmapmalloc(3LIB), proc(4), attributes(5)

				 Jan 10, 2007		  WATCHMALLOC(3MALLOC)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net