leak 4.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211
  1. .TH LEAK 1
  2. .SH NAME
  3. leak, kmem \- help find memory leaks
  4. .SH SYNOPSIS
  5. .B leak
  6. [
  7. .B -abcds
  8. ]
  9. [
  10. .B -f
  11. .I binary
  12. ]
  13. [
  14. .B -r
  15. .I res
  16. ]
  17. [
  18. .B -x
  19. .I width
  20. ]
  21. .I pid ...
  22. .PP
  23. .B kmem
  24. [
  25. .I kernel
  26. ]
  27. .SH DESCRIPTION
  28. .I Leak
  29. examines the named processes, which
  30. should be sharing their data and bss segments,
  31. for memory leaks.
  32. It uses a mark and sweep-style algorithm to
  33. determine which allocated blocks are no longer
  34. reachable from the set of root pointers.
  35. The set of root pointers is created by looking through
  36. the shared bss segment as well as each process's registers.
  37. .PP
  38. Unless directed otherwise,
  39. .I leak
  40. prints, for each block, a line with seven space-separated fields:
  41. the string
  42. .BR block ,
  43. the address of the block,
  44. the size of the block,
  45. the first two words of the block,
  46. and the function names represented by the first two words of the block.
  47. Usually, the first two words of the block
  48. contain the malloc and realloc tags
  49. (see
  50. .IR malloc (2)),
  51. useful for finding who allocated the leaked blocks.
  52. .PP
  53. If the
  54. .B -s
  55. or the
  56. .B -c
  57. option is given,
  58. .I leak
  59. will instead present a sequence of
  60. .IR acid (1)
  61. commands that show each leaky allocation site.
  62. With
  63. .B -s
  64. a comment appears next to each command to
  65. indicate how many lost blocks were allocated
  66. at that point in the program.
  67. With
  68. .B -c
  69. the comments are extended to indicate also the total
  70. number of bytes lost at that point in the program,
  71. and an additional comment line gives the
  72. overall total number of bytes.
  73. .PP
  74. If the
  75. .B -a
  76. option is given,
  77. .I leak
  78. will print information as decribed above,
  79. but for all allocated blocks,
  80. not only leaked ones.
  81. If the
  82. .B -d
  83. option is given,
  84. .I leak
  85. will print information as decribed above,
  86. but for all free blocks,
  87. i.e. those freed,
  88. or those that are not yet
  89. in use (fragmentation?).
  90. The
  91. .B -a
  92. and
  93. .B -d
  94. options can be combined.
  95. .PP
  96. If the
  97. .B -b
  98. option is given,
  99. .I leak
  100. will print a Plan 9 image file
  101. graphically summarizing the memory arenas.
  102. In the image, each pixel represents
  103. .I res
  104. (default 8)
  105. bytes.
  106. The color code is:
  107. .TP "\w'\fIbright blue\fR 'u
  108. .I "dark blue
  109. Completely allocated.
  110. .TP
  111. .I "bright blue
  112. Contains malloc headers.
  113. .TP
  114. .I "bright red
  115. Contains malloc headers for leaked memory.
  116. .TP
  117. .I "dark red
  118. Contains leaked memory.
  119. .TP
  120. .I "yellow
  121. Completely free
  122. .TP
  123. .I "white
  124. Padding to fill out the image.
  125. .PD
  126. The bright pixels representing headers help in
  127. counting the number of blocks.
  128. Magnifying the images with
  129. .IR lens (1)
  130. is often useful.
  131. .PP
  132. If given a name rather than a list of process ids,
  133. .I leak
  134. echoes back a command-line with process ids of every process
  135. with that name.
  136. .PP
  137. The
  138. .B -f
  139. option specifies a binary to go on the
  140. .IR acid (1)
  141. command-line used to inspect the
  142. processes, and is only necessary
  143. when inspecting processes started
  144. from stripped binaries.
  145. .PP
  146. .I Kmem
  147. prints a summary of all allocated blocks in the running kernel.
  148. Each line of the summary gives
  149. the count and total size of blocks allocated at an allocation point.
  150. The list is sorted by count in decreasing order.
  151. .SH EXAMPLES
  152. List lost blocks in
  153. .IR 8.out .
  154. This depends on the fact that there is only
  155. once instance of
  156. .I 8.out
  157. running; if there were more, the output of
  158. .B "leak -s 8.out
  159. would need editing before sending to the shell.
  160. .IP
  161. .EX
  162. % leak -s 8.out
  163. leak -s 229 230
  164. % leak -s 8.out | rc
  165. src(0x0000bf1b); // 64
  166. src(0x000016f5); // 7
  167. src(0x0000a988); // 7
  168. %
  169. .EE
  170. .LP
  171. View the memory usage graphic for the window system.
  172. .IP
  173. .EX
  174. % leak -b rio | rc | page
  175. .EE
  176. .PP
  177. List the top allocation points in the kernel,
  178. first by count and then by total size:
  179. .IP
  180. .EX
  181. % kmem | sed 10q
  182. % kmem | sort -nr +1 | sed 10q
  183. .EE
  184. .SH SOURCE
  185. .B /sys/lib/acid/leak
  186. .br
  187. .B /sys/src/cmd/aux/acidleak.c
  188. .br
  189. .B /rc/bin/leak
  190. .br
  191. .B /rc/bin/kmem
  192. .SH SEE ALSO
  193. .IR getcallerpc (2),
  194. .I setmalloctag
  195. in
  196. .IR malloc (2)
  197. .SH BUGS
  198. .I Leak
  199. and
  200. .I kmem
  201. depend on the internal structure of the
  202. libc pool memory allocator (see
  203. .IR pool (2)).
  204. Since the ANSI/POSIX environment uses a different
  205. allocator,
  206. .I leak
  207. will not work on APE programs.
  208. .PP
  209. It's not speedy, and
  210. .I acidleak
  211. can consume more memory than the process(es) being examined.