File: manual-core.xml

package info (click to toggle)
valgrind 1%3A3.12.0~svn20160714-1
  • links: PTS, VCS
  • area: main
  • in suites: stretch
  • size: 120,428 kB
  • ctags: 70,855
  • sloc: ansic: 674,645; exp: 26,134; xml: 21,574; asm: 7,570; cpp: 7,567; makefile: 7,380; sh: 6,188; perl: 5,855; haskell: 195
file content (3143 lines) | stat: -rw-r--r-- 141,127 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
<?xml version="1.0"?> <!-- -*- sgml -*- -->
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[ <!ENTITY % vg-entities SYSTEM "vg-entities.xml"> %vg-entities; ]>


<chapter id="manual-core" xreflabel="Valgrind's core">
<title>Using and understanding the Valgrind core</title>

<para>This chapter describes the Valgrind core services, command-line
options and behaviours.  That means it is relevant regardless of what
particular tool you are using.  The information should be sufficient for you
to make effective day-to-day use of Valgrind.  Advanced topics related to
the Valgrind core are described in <xref linkend="manual-core-adv"/>.
</para>

<para>
A point of terminology: most references to "Valgrind" in this chapter
refer to the Valgrind core services.  </para>



<sect1 id="manual-core.whatdoes" 
       xreflabel="What Valgrind does with your program">
<title>What Valgrind does with your program</title>

<para>Valgrind is designed to be as non-intrusive as possible. It works
directly with existing executables. You don't need to recompile, relink,
or otherwise modify the program to be checked.</para>

<para>You invoke Valgrind like this:</para>
<programlisting><![CDATA[
valgrind [valgrind-options] your-prog [your-prog-options]]]></programlisting>

<para>The most important option is <option>--tool</option> which dictates
which Valgrind tool to run.  For example, if want to run the command
<computeroutput>ls -l</computeroutput> using the memory-checking tool
Memcheck, issue this command:</para>

<programlisting><![CDATA[
valgrind --tool=memcheck ls -l]]></programlisting>

<para>However, Memcheck is the default, so if you want to use it you can
omit the <option>--tool</option> option.</para>

<para>Regardless of which tool is in use, Valgrind takes control of your
program before it starts.  Debugging information is read from the
executable and associated libraries, so that error messages and other
outputs can be phrased in terms of source code locations, when
appropriate.</para>

<para>Your program is then run on a synthetic CPU provided by the
Valgrind core.  As new code is executed for the first time, the core
hands the code to the selected tool.  The tool adds its own
instrumentation code to this and hands the result back to the core,
which coordinates the continued execution of this instrumented
code.</para>

<para>The amount of instrumentation code added varies widely between
tools.  At one end of the scale, Memcheck adds code to check every
memory access and every value computed,
making it run 10-50 times slower than natively.
At the other end of the spectrum, the minimal tool, called Nulgrind,
adds no instrumentation at all and causes in total "only" about a 4 times
slowdown.</para>

<para>Valgrind simulates every single instruction your program executes.
Because of this, the active tool checks, or profiles, not only the code
in your application but also in all supporting dynamically-linked libraries,
including the C library, graphical libraries, and so on.</para>

<para>If you're using an error-detection tool, Valgrind may
detect errors in system libraries, for example the GNU C or X11
libraries, which you have to use.  You might not be interested in these
errors, since you probably have no control over that code.  Therefore,
Valgrind allows you to selectively suppress errors, by recording them in
a suppressions file which is read when Valgrind starts up.  The build
mechanism selects default suppressions which give reasonable
behaviour for the OS and libraries detected on your machine.
To make it easier to write suppressions, you can use the
<option>--gen-suppressions=yes</option> option.  This tells Valgrind to
print out a suppression for each reported error, which you can then
copy into a suppressions file.</para>

<para>Different error-checking tools report different kinds of errors.
The suppression mechanism therefore allows you to say which tool or
tool(s) each suppression applies to.</para>

</sect1>


<sect1 id="manual-core.started" xreflabel="Getting started">
<title>Getting started</title>

<para>First off, consider whether it might be beneficial to recompile
your application and supporting libraries with debugging info enabled
(the <option>-g</option> option).  Without debugging info, the best
Valgrind tools will be able to do is guess which function a particular
piece of code belongs to, which makes both error messages and profiling
output nearly useless.  With <option>-g</option>, you'll get
messages which point directly to the relevant source code lines.</para>

<para>Another option you might like to consider, if you are working with
C++, is <option>-fno-inline</option>.  That makes it easier to see the
function-call chain, which can help reduce confusion when navigating
around large C++ apps.  For example, debugging
OpenOffice.org with Memcheck is a bit easier when using this option.  You
don't have to do this, but doing so helps Valgrind produce more accurate
and less confusing error reports.  Chances are you're set up like this
already, if you intended to debug your program with GNU GDB, or some
other debugger. Alternatively, the Valgrind option 
<option>--read-inline-info=yes</option> instructs Valgrind to read
the debug information describing inlining information. With this,
function call chain will be properly shown, even when your application
is compiled with inlining. </para>

<para>If you are planning to use Memcheck: On rare
occasions, compiler optimisations (at <option>-O2</option>
and above, and sometimes <option>-O1</option>) have been
observed to generate code which fools Memcheck into wrongly reporting
uninitialised value errors, or missing uninitialised value errors.  We have
looked in detail into fixing this, and unfortunately the result is that
doing so would give a further significant slowdown in what is already a slow
tool.  So the best solution is to turn off optimisation altogether.  Since
this often makes things unmanageably slow, a reasonable compromise is to use
<option>-O</option>.  This gets you the majority of the
benefits of higher optimisation levels whilst keeping relatively small the
chances of false positives or false negatives from Memcheck.  Also, you
should compile your code with <option>-Wall</option> because
it can identify some or all of the problems that Valgrind can miss at the
higher optimisation levels.  (Using <option>-Wall</option>
is also a good idea in general.)  All other tools (as far as we know) are
unaffected by optimisation level, and for profiling tools like Cachegrind it
is better to compile your program at its normal optimisation level.</para>

<para>Valgrind understands the DWARF2/3/4 formats used by GCC 3.1 and
later.  The reader for "stabs" debugging format (used by GCC versions
prior to 3.1) has been disabled in Valgrind 3.9.0.</para>

<para>When you're ready to roll, run Valgrind as described above.
Note that you should run the real
(machine-code) executable here.  If your application is started by, for
example, a shell or Perl script, you'll need to modify it to invoke
Valgrind on the real executables.  Running such scripts directly under
Valgrind will result in you getting error reports pertaining to
<filename>/bin/sh</filename>,
<filename>/usr/bin/perl</filename>, or whatever interpreter
you're using.  This may not be what you want and can be confusing.  You
can force the issue by giving the option
<option>--trace-children=yes</option>, but confusion is still
likely.</para>

</sect1>


<!-- Referenced from both the manual and manpage -->
<sect1 id="&vg-comment-id;" xreflabel="&vg-comment-label;">
<title>The Commentary</title>

<para>Valgrind tools write a commentary, a stream of text, detailing
error reports and other significant events.  All lines in the commentary
have following form:

<programlisting><![CDATA[
==12345== some-message-from-Valgrind]]></programlisting>
</para>

<para>The <computeroutput>12345</computeroutput> is the process ID.
This scheme makes it easy to distinguish program output from Valgrind
commentary, and also easy to differentiate commentaries from different
processes which have become merged together, for whatever reason.</para>

<para>By default, Valgrind tools write only essential messages to the
commentary, so as to avoid flooding you with information of secondary
importance.  If you want more information about what is happening,
re-run, passing the <option>-v</option> option to Valgrind.  A second
<option>-v</option> gives yet more detail.
</para>

<para>You can direct the commentary to three different places:</para>

<orderedlist>

  <listitem id="manual-core.out2fd" xreflabel="Directing output to fd">
    <para>The default: send it to a file descriptor, which is by default
    2 (stderr).  So, if you give the core no options, it will write
    commentary to the standard error stream.  If you want to send it to
    some other file descriptor, for example number 9, you can specify
    <option>--log-fd=9</option>.</para>

    <para>This is the simplest and most common arrangement, but can
    cause problems when Valgrinding entire trees of processes which
    expect specific file descriptors, particularly stdin/stdout/stderr,
    to be available for their own use.</para>
  </listitem>

  <listitem id="manual-core.out2file" 
            xreflabel="Directing output to file"> <para>A less intrusive
    option is to write the commentary to a file, which you specify by
    <option>--log-file=filename</option>.  There are special format
    specifiers that can be used to use a process ID or an environment
    variable name in the log file name.  These are useful/necessary if your
    program invokes multiple processes (especially for MPI programs).
    See the <link linkend="manual-core.basicopts">basic options section</link>
    for more details.</para>
  </listitem>

  <listitem id="manual-core.out2socket" 
            xreflabel="Directing output to network socket"> <para>The
    least intrusive option is to send the commentary to a network
    socket.  The socket is specified as an IP address and port number
    pair, like this: <option>--log-socket=192.168.0.1:12345</option> if
    you want to send the output to host IP 192.168.0.1 port 12345
    (note: we
    have no idea if 12345 is a port of pre-existing significance).  You
    can also omit the port number:
    <option>--log-socket=192.168.0.1</option>, in which case a default
    port of 1500 is used.  This default is defined by the constant
    <computeroutput>VG_CLO_DEFAULT_LOGPORT</computeroutput> in the
    sources.</para>

    <para>Note, unfortunately, that you have to use an IP address here,
    rather than a hostname.</para>

    <para>Writing to a network socket is pointless if you don't
    have something listening at the other end.  We provide a simple
    listener program,
    <computeroutput>valgrind-listener</computeroutput>, which accepts
    connections on the specified port and copies whatever it is sent to
    stdout.  Probably someone will tell us this is a horrible security
    risk.  It seems likely that people will write more sophisticated
    listeners in the fullness of time.</para>

    <para><computeroutput>valgrind-listener</computeroutput> can accept
    simultaneous connections from up to 50 Valgrinded processes.  In front
    of each line of output it prints the current number of active
    connections in round brackets.</para>

    <para><computeroutput>valgrind-listener</computeroutput> accepts three
    command-line options:</para>
    <!-- start of xi:include in the manpage -->
    <variablelist id="listener.opts.list">
       <varlistentry>
         <term><option>-e --exit-at-zero</option></term>
         <listitem>
           <para>When the number of connected processes falls back to zero,
           exit.  Without this, it will run forever, that is, until you
           send it Control-C.</para>
         </listitem>
       </varlistentry>
       <varlistentry>
         <term><option>--max-connect=INTEGER</option></term>
         <listitem>
           <para>By default, the listener can connect to up to 50 processes.
             Occasionally, that number is too small. Use this option to
             provide a different limit. E.g.
             <computeroutput>--max-connect=100</computeroutput>.
           </para>
         </listitem>
       </varlistentry>
       <varlistentry>
        <term><option>portnumber</option></term>
        <listitem>
          <para>Changes the port it listens on from the default (1500).
          The specified port must be in the range 1024 to 65535.
          The same restriction applies to port numbers specified by a
          <option>--log-socket</option> to Valgrind itself.</para>
        </listitem>
      </varlistentry>
    </variablelist>
    <!-- end of xi:include in the manpage -->

    <para>If a Valgrinded process fails to connect to a listener, for
    whatever reason (the listener isn't running, invalid or unreachable
    host or port, etc), Valgrind switches back to writing the commentary
    to stderr.  The same goes for any process which loses an established
    connection to a listener.  In other words, killing the listener
    doesn't kill the processes sending data to it.</para>
  </listitem>

</orderedlist>

<para>Here is an important point about the relationship between the
commentary and profiling output from tools.  The commentary contains a
mix of messages from the Valgrind core and the selected tool.  If the
tool reports errors, it will report them to the commentary.  However, if
the tool does profiling, the profile data will be written to a file of
some kind, depending on the tool, and independent of what
<option>--log-*</option> options are in force.  The commentary is
intended to be a low-bandwidth, human-readable channel.  Profiling data,
on the other hand, is usually voluminous and not meaningful without
further processing, which is why we have chosen this arrangement.</para>

</sect1>


<sect1 id="manual-core.report" xreflabel="Reporting of errors">
<title>Reporting of errors</title>

<para>When an error-checking tool
detects something bad happening in the program, an error
message is written to the commentary.  Here's an example from Memcheck:</para>

<programlisting><![CDATA[
==25832== Invalid read of size 4
==25832==    at 0x8048724: BandMatrix::ReSize(int, int, int) (bogon.cpp:45)
==25832==    by 0x80487AF: main (bogon.cpp:66)
==25832==  Address 0xBFFFF74C is not stack'd, malloc'd or free'd]]></programlisting>

<para>This message says that the program did an illegal 4-byte read of
address 0xBFFFF74C, which, as far as Memcheck can tell, is not a valid
stack address, nor corresponds to any current heap blocks or recently freed
heap blocks.  The read is happening at line 45 of
<filename>bogon.cpp</filename>, called from line 66 of the same file,
etc.  For errors associated with an identified (current or freed) heap block,
for example reading freed memory, Valgrind reports not only the
location where the error happened, but also where the associated heap block
was allocated/freed.</para>

<para>Valgrind remembers all error reports.  When an error is detected,
it is compared against old reports, to see if it is a duplicate.  If so,
the error is noted, but no further commentary is emitted.  This avoids
you being swamped with bazillions of duplicate error reports.</para>

<para>If you want to know how many times each error occurred, run with
the <option>-v</option> option.  When execution finishes, all the
reports are printed out, along with, and sorted by, their occurrence
counts.  This makes it easy to see which errors have occurred most
frequently.</para>

<para>Errors are reported before the associated operation actually
happens.  For example, if you're using Memcheck and your program attempts to
read from address zero, Memcheck will emit a message to this effect, and
your program will then likely die with a segmentation fault.</para>

<para>In general, you should try and fix errors in the order that they
are reported.  Not doing so can be confusing.  For example, a program
which copies uninitialised values to several memory locations, and later
uses them, will generate several error messages, when run on Memcheck.
The first such error message may well give the most direct clue to the
root cause of the problem.</para>

<para>The process of detecting duplicate errors is quite an
expensive one and can become a significant performance overhead
if your program generates huge quantities of errors.  To avoid
serious problems, Valgrind will simply stop collecting
errors after 1,000 different errors have been seen, or 10,000,000 errors
in total have been seen.  In this situation you might as well
stop your program and fix it, because Valgrind won't tell you
anything else useful after this.  Note that the 1,000/10,000,000 limits
apply after suppressed errors are removed.  These limits are
defined in <filename>m_errormgr.c</filename> and can be increased
if necessary.</para>

<para>To avoid this cutoff you can use the
<option>--error-limit=no</option> option.  Then Valgrind will always show
errors, regardless of how many there are.  Use this option carefully,
since it may have a bad effect on performance.</para>

</sect1>


<sect1 id="manual-core.suppress" xreflabel="Suppressing errors">
<title>Suppressing errors</title>

<para>The error-checking tools detect numerous problems in the system
libraries, such as the C library, 
which come pre-installed with your OS.  You can't easily fix
these, but you don't want to see these errors (and yes, there are many!)
So Valgrind reads a list of errors to suppress at startup.  A default
suppression file is created by the
<computeroutput>./configure</computeroutput> script when the system is
built.</para>

<para>You can modify and add to the suppressions file at your leisure,
or, better, write your own.  Multiple suppression files are allowed.
This is useful if part of your project contains errors you can't or
don't want to fix, yet you don't want to continuously be reminded of
them.</para>

<formalpara><title>Note:</title> <para>By far the easiest way to add
suppressions is to use the <option>--gen-suppressions=yes</option> option
described in <xref linkend="manual-core.options"/>.  This generates
suppressions automatically.  For best results,
though, you may want to edit the output
    of  <option>--gen-suppressions=yes</option> by hand, in which
case it would be advisable to read through this section.
</para>
</formalpara>

<para>Each error to be suppressed is described very specifically, to
minimise the possibility that a suppression-directive inadvertently
suppresses a bunch of similar errors which you did want to see.  The
suppression mechanism is designed to allow precise yet flexible
specification of errors to suppress.</para>

<para>If you use the <option>-v</option> option, at the end of execution,
Valgrind prints out one line for each used suppression, giving the number of times
it got used, its name and the filename and line number where the suppression is
defined. Depending on the suppression kind, the filename and line number are optionally
followed by additional information (such as the number of blocks and bytes suppressed
by a memcheck leak suppression). Here's the suppressions used by a
run of <computeroutput>valgrind -v --tool=memcheck ls -l</computeroutput>:</para>

<programlisting><![CDATA[
--1610-- used_suppression:      2 dl-hack3-cond-1 /usr/lib/valgrind/default.supp:1234
--1610-- used_suppression:      2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a /usr/lib/valgrind/default.supp:1234
]]></programlisting>

<para>Multiple suppressions files are allowed.  Valgrind loads suppression
patterns from <filename>$PREFIX/lib/valgrind/default.supp</filename> unless
<option>--default-suppressions=no</option> has been specified.  You can
ask to add suppressions from additional files by specifying
<option>--suppressions=/path/to/file.supp</option> one or more times.
</para>

<para>If you want to understand more about suppressions, look at an
existing suppressions file whilst reading the following documentation.
The file <filename>glibc-2.3.supp</filename>, in the source
distribution, provides some good examples.</para>

<para>Each suppression has the following components:</para>

<itemizedlist>

  <listitem>
    <para>First line: its name.  This merely gives a handy name to the
    suppression, by which it is referred to in the summary of used
    suppressions printed out when a program finishes.  It's not
    important what the name is; any identifying string will do.</para>
  </listitem>

  <listitem>
    <para>Second line: name of the tool(s) that the suppression is for
    (if more than one, comma-separated), and the name of the suppression
    itself, separated by a colon (n.b.: no spaces are allowed), eg:</para>
<programlisting><![CDATA[
tool_name1,tool_name2:suppression_name]]></programlisting>

    <para>Recall that Valgrind is a modular system, in which
    different instrumentation tools can observe your program whilst it
    is running.  Since different tools detect different kinds of errors,
    it is necessary to say which tool(s) the suppression is meaningful
    to.</para>

    <para>Tools will complain, at startup, if a tool does not understand
    any suppression directed to it.  Tools ignore suppressions which are
    not directed to them.  As a result, it is quite practical to put
    suppressions for all tools into the same suppression file.</para>
  </listitem>

  <listitem>
    <para>Next line: a small number of suppression types have extra
    information after the second line (eg. the <varname>Param</varname>
    suppression for Memcheck)</para>
  </listitem>

  <listitem>
    <para>Remaining lines: This is the calling context for the error --
    the chain of function calls that led to it.  There can be up to 24
    of these lines.</para>

    <para>Locations may be names of either shared objects or
    functions.  They begin
    <computeroutput>obj:</computeroutput> and
    <computeroutput>fun:</computeroutput> respectively.  Function and
    object names to match against may use the wildcard characters
    <computeroutput>*</computeroutput> and
    <computeroutput>?</computeroutput>.</para>

    <para><command>Important note: </command> C++ function names must be
    <command>mangled</command>.  If you are writing suppressions by
    hand, use the <option>--demangle=no</option> option to get the
    mangled names in your error messages.  An example of a mangled
    C++ name is  <computeroutput>_ZN9QListView4showEv</computeroutput>.
    This is the form that the GNU C++ compiler uses internally, and
    the form that must be used in suppression files.  The equivalent
    demangled name, <computeroutput>QListView::show()</computeroutput>,
    is what you see at the C++ source code level.
    </para>

    <para>A location line may also be
    simply "<computeroutput>...</computeroutput>" (three dots).  This is
    a frame-level wildcard, which matches zero or more frames.  Frame
    level wildcards are useful because they make it easy to ignore
    varying numbers of uninteresting frames in between frames of
    interest.  That is often important when writing suppressions which
    are intended to be robust against variations in the amount of
    function inlining done by compilers.</para>
  </listitem>

  <listitem>
    <para>Finally, the entire suppression must be between curly
    braces. Each brace must be the first character on its own
    line.</para>
  </listitem>

 </itemizedlist>

<para>A suppression only suppresses an error when the error matches all
the details in the suppression.  Here's an example:</para>

<programlisting><![CDATA[
{
  __gconv_transform_ascii_internal/__mbrtowc/mbtowc
  Memcheck:Value4
  fun:__gconv_transform_ascii_internal
  fun:__mbr*toc
  fun:mbtowc
}]]></programlisting>


<para>What it means is: for Memcheck only, suppress a
use-of-uninitialised-value error, when the data size is 4, when it
occurs in the function
<computeroutput>__gconv_transform_ascii_internal</computeroutput>, when
that is called from any function of name matching
<computeroutput>__mbr*toc</computeroutput>, when that is called from
<computeroutput>mbtowc</computeroutput>.  It doesn't apply under any
other circumstances.  The string by which this suppression is identified
to the user is
<computeroutput>__gconv_transform_ascii_internal/__mbrtowc/mbtowc</computeroutput>.</para>

<para>(See <xref linkend="mc-manual.suppfiles"/> for more details
on the specifics of Memcheck's suppression kinds.)</para>

<para>Another example, again for the Memcheck tool:</para>

<programlisting><![CDATA[
{
  libX11.so.6.2/libX11.so.6.2/libXaw.so.7.0
  Memcheck:Value4
  obj:/usr/X11R6/lib/libX11.so.6.2
  obj:/usr/X11R6/lib/libX11.so.6.2
  obj:/usr/X11R6/lib/libXaw.so.7.0
}]]></programlisting>

<para>This suppresses any size 4 uninitialised-value error which occurs
anywhere in <filename>libX11.so.6.2</filename>, when called from
anywhere in the same library, when called from anywhere in
<filename>libXaw.so.7.0</filename>.  The inexact specification of
locations is regrettable, but is about all you can hope for, given that
the X11 libraries shipped on the Linux distro on which this example
was made have had their symbol tables removed.</para>

<para>Although the above two examples do not make this clear, you can
freely mix <computeroutput>obj:</computeroutput> and
<computeroutput>fun:</computeroutput> lines in a suppression.</para>

<para>Finally, here's an example using three frame-level wildcards:</para>

<programlisting><![CDATA[
{
   a-contrived-example
   Memcheck:Leak
   fun:malloc
   ...
   fun:ddd
   ...
   fun:ccc
   ...
   fun:main
}
]]></programlisting>
This suppresses Memcheck memory-leak errors, in the case where
the allocation was done by <computeroutput>main</computeroutput>
calling (though any number of intermediaries, including zero)
<computeroutput>ccc</computeroutput>,
calling onwards via
<computeroutput>ddd</computeroutput> and eventually
to <computeroutput>malloc.</computeroutput>.
</sect1>


<sect1 id="manual-core.options" 
       xreflabel="Core Command-line Options">
<title>Core Command-line Options</title>

<para>As mentioned above, Valgrind's core accepts a common set of options.
The tools also accept tool-specific options, which are documented
separately for each tool.</para>

<para>Valgrind's default settings succeed in giving reasonable behaviour
in most cases.  We group the available options by rough categories.</para>

<sect2 id="manual-core.toolopts" xreflabel="Tool-selection Option">
<title>Tool-selection Option</title>

<para id="tool.opts.para">The single most important option.</para>

<variablelist id="tool.opts.list">

  <varlistentry id="tool_name" xreflabel="--tool">
    <term>
      <option><![CDATA[--tool=<toolname> [default: memcheck] ]]></option>
    </term>
    <listitem>
      <para>Run the Valgrind tool called <varname>toolname</varname>,
      e.g. memcheck, cachegrind, callgrind, helgrind, drd, massif,
      lackey, none, exp-sgcheck, exp-bbv, exp-dhat, etc.</para>
    </listitem>
  </varlistentry>

</variablelist>

</sect2>



<sect2 id="manual-core.basicopts" xreflabel="Basic Options">
<title>Basic Options</title>

<!-- start of xi:include in the manpage -->
<para id="basic.opts.para">These options work with all tools.</para>

<variablelist id="basic.opts.list">

  <varlistentry id="opt.help" xreflabel="--help">
    <term><option>-h --help</option></term>
    <listitem>
      <para>Show help for all options, both for the core and for the
      selected tool.  If the option is repeated it is equivalent to giving
      <option>--help-debug</option>.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.help-debug" xreflabel="--help-debug">
    <term><option>--help-debug</option></term>
    <listitem>
      <para>Same as <option>--help</option>, but also lists debugging
      options which usually are only of use to Valgrind's
      developers.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.version" xreflabel="--version">
    <term><option>--version</option></term>
    <listitem>
      <para>Show the version number of the Valgrind core. Tools can have
      their own version numbers. There is a scheme in place to ensure
      that tools only execute when the core version is one they are
      known to work with. This was done to minimise the chances of
      strange problems arising from tool-vs-core version
      incompatibilities.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.quiet" xreflabel="--quiet">
    <term><option>-q</option>, <option>--quiet</option></term>
    <listitem>
      <para>Run silently, and only print error messages. Useful if you
      are running regression tests or have some other automated test
      machinery.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.verbose" xreflabel="--verbose">
    <term><option>-v</option>, <option>--verbose</option></term>
    <listitem>
      <para>Be more verbose. Gives extra information on various aspects
      of your program, such as: the shared objects loaded, the
      suppressions used, the progress of the instrumentation and
      execution engines, and warnings about unusual behaviour. Repeating
      the option increases the verbosity level.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.trace-children" xreflabel="--trace-children">
    <term>
      <option><![CDATA[--trace-children=<yes|no> [default: no] ]]></option>
    </term>
    <listitem>
      <para>When enabled, Valgrind will trace into sub-processes
      initiated via the <varname>exec</varname> system call.  This is
      necessary for multi-process programs.
      </para>
      <para>Note that Valgrind does trace into the child of a
      <varname>fork</varname> (it would be difficult not to, since
      <varname>fork</varname> makes an identical copy of a process), so this
      option is arguably badly named.  However, most children of
      <varname>fork</varname> calls immediately call <varname>exec</varname>
      anyway.
      </para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.trace-children-skip" xreflabel="--trace-children-skip">
    <term>
      <option><![CDATA[--trace-children-skip=patt1,patt2,... ]]></option>
    </term>
    <listitem>
      <para>This option only has an effect when 
        <option>--trace-children=yes</option> is specified.  It allows
        for some children to be skipped.  The option takes a comma
        separated list of patterns for the names of child executables
        that Valgrind should not trace into.  Patterns may include the
        metacharacters <computeroutput>?</computeroutput>
        and <computeroutput>*</computeroutput>, which have the usual
        meaning.</para>
      <para>
        This can be useful for pruning uninteresting branches from a
        tree of processes being run on Valgrind.  But you should be
        careful when using it.  When Valgrind skips tracing into an
        executable, it doesn't just skip tracing that executable, it
        also skips tracing any of that executable's child processes.
        In other words, the flag doesn't merely cause tracing to stop
        at the specified executables -- it skips tracing of entire
        process subtrees rooted at any of the specified
        executables.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.trace-children-skip-by-arg"
                xreflabel="--trace-children-skip-by-arg">
    <term>
      <option><![CDATA[--trace-children-skip-by-arg=patt1,patt2,... ]]></option>
    </term>
    <listitem>
      <para>This is the same as  
        <option>--trace-children-skip</option>, with one difference:
        the decision as to whether to trace into a child process is
        made by examining the arguments to the child process, rather
        than the name of its executable.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.child-silent-after-fork"
                xreflabel="--child-silent-after-fork">
    <term>
      <option><![CDATA[--child-silent-after-fork=<yes|no> [default: no] ]]></option>
    </term>
    <listitem>
      <para>When enabled, Valgrind will not show any debugging or
      logging output for the child process resulting from
      a <varname>fork</varname> call.  This can make the output less
      confusing (although more misleading) when dealing with processes
      that create children.  It is particularly useful in conjunction
      with <varname>--trace-children=</varname>.  Use of this option is also
      strongly recommended if you are requesting XML output
      (<varname>--xml=yes</varname>), since otherwise the XML from child and
      parent may become mixed up, which usually makes it useless.
      </para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.vgdb" xreflabel="--vgdb">
    <term>
      <option><![CDATA[--vgdb=<no|yes|full> [default: yes] ]]></option>
    </term>
    <listitem>
      
      <para>Valgrind will provide "gdbserver" functionality when
      <option>--vgdb=yes</option> or <option>--vgdb=full</option> is
      specified.  This allows an external GNU GDB debugger to control
      and debug your program when it runs on Valgrind.
      <option>--vgdb=full</option> incurs significant performance
      overheads, but provides more precise breakpoints and
      watchpoints. See <xref linkend="manual-core-adv.gdbserver"/> for
      a detailed description.
      </para>

      <para> If the embedded gdbserver is enabled but no gdb is
      currently being used, the <xref linkend="manual-core-adv.vgdb"/>
      command line utility can send "monitor commands" to Valgrind
      from a shell.  The Valgrind core provides a set of
      <xref linkend="manual-core-adv.valgrind-monitor-commands"/>. A tool
      can optionally provide tool specific monitor commands, which are
      documented in the tool specific chapter.
      </para>

    </listitem>
  </varlistentry>

  <varlistentry id="opt.vgdb-error" xreflabel="--vgdb-error">
    <term>
      <option><![CDATA[--vgdb-error=<number> [default: 999999999] ]]></option>
    </term>
    <listitem>
      <para> Use this option when the Valgrind gdbserver is enabled with
      <option>--vgdb=yes</option> or <option>--vgdb=full</option>.
      Tools that report errors will wait
      for "<computeroutput>number</computeroutput>" errors to be
      reported before freezing the program and waiting for you to
      connect with GDB.  It follows that a value of zero will cause
      the gdbserver to be started before your program is executed.
      This is typically used to insert GDB breakpoints before
      execution, and also works with tools that do not report
      errors, such as Massif.
      </para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.vgdb-stop-at" xreflabel="--vgdb-stop-at">
    <term>
      <option><![CDATA[--vgdb-stop-at=<set> [default: none] ]]></option>
    </term>
    <listitem>
      <para> Use this option when the Valgrind gdbserver is enabled with
      <option>--vgdb=yes</option> or <option>--vgdb=full</option>.
      The Valgrind gdbserver will be invoked for each error after
      <option>--vgdb-error</option> have been reported.
      You can additionally ask the Valgrind gdbserver to be invoked
      for other events, specified in one of the following ways:  </para>
      <itemizedlist>
        <listitem><para>a comma separated list of one or more of
            <option>startup exit valgrindabexit</option>.</para>

          <para>The values <option>startup</option> <option>exit</option>
          <option>valgrindabexit</option> respectively indicate to
          invoke gdbserver before your program is executed, after the
          last instruction of your program, on Valgrind abnormal exit
          (e.g. internal error, out of memory, ...).</para>

          <para>Note: <option>startup</option> and
          <option>--vgdb-error=0</option> will both cause Valgrind
          gdbserver to be invoked before your program is executed. The
          <option>--vgdb-error=0</option> will in addition cause your 
          program to stop on all subsequent errors.</para>

        </listitem>
        
        <listitem><para><option>all</option> to specify the complete set.
            It is equivalent to
            <option>--vgdb-stop-at=startup,exit,valgrindabexit</option>.</para>
        </listitem>
        
        <listitem><para><option>none</option> for the empty set.</para>
        </listitem>
      </itemizedlist>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.track-fds" xreflabel="--track-fds">
    <term>
      <option><![CDATA[--track-fds=<yes|no> [default: no] ]]></option>
    </term>
    <listitem>
      <para>When enabled, Valgrind will print out a list of open file
      descriptors on exit or on request, via the gdbserver monitor
      command <varname>v.info open_fds</varname>.  Along with each
      file descriptor is printed a stack backtrace of where the file
      was opened and any details relating to the file descriptor such
      as the file name or socket details.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.time-stamp" xreflabel="--time-stamp">
    <term>
      <option><![CDATA[--time-stamp=<yes|no> [default: no] ]]></option>
    </term>
    <listitem>
      <para>When enabled, each message is preceded with an indication of
      the elapsed wallclock time since startup, expressed as days,
      hours, minutes, seconds and milliseconds.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.log-fd" xreflabel="--log-fd">
    <term>
      <option><![CDATA[--log-fd=<number> [default: 2, stderr] ]]></option>
    </term>
    <listitem>
      <para>Specifies that Valgrind should send all of its messages to
      the specified file descriptor.  The default, 2, is the standard
      error channel (stderr).  Note that this may interfere with the
      client's own use of stderr, as Valgrind's output will be
      interleaved with any output that the client sends to
      stderr.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.log-file" xreflabel="--log-file">
    <term>
      <option><![CDATA[--log-file=<filename> ]]></option>
    </term>
    <listitem>
      <para>Specifies that Valgrind should send all of its messages to
      the specified file.  If the file name is empty, it causes an abort.
      There are three special format specifiers that can be used in the file
      name.</para>

      <para><option>%p</option> is replaced with the current process ID.
      This is very useful for program that invoke multiple processes.
      WARNING: If you use <option>--trace-children=yes</option> and your
      program invokes multiple processes OR your program forks without
      calling exec afterwards, and you don't use this specifier
      (or the <option>%q</option> specifier below), the Valgrind output from
      all those processes will go into one file, possibly jumbled up, and
      possibly incomplete.</para>

      <para><option>%q{FOO}</option> is replaced with the contents of the
      environment variable <varname>FOO</varname>.  If the
      <option>{FOO}</option> part is malformed, it causes an abort.  This
      specifier is rarely needed, but very useful in certain circumstances
      (eg. when running MPI programs).  The idea is that you specify a
      variable which will be set differently for each process in the job,
      for example <computeroutput>BPROC_RANK</computeroutput> or whatever is
      applicable in your MPI setup.  If the named environment variable is not
      set, it causes an abort.  Note that in some shells, the
      <option>{</option> and <option>}</option> characters may need to be
      escaped with a backslash.</para>

      <para><option>%%</option> is replaced with <option>%</option>.</para>
      
      <para>If an <option>%</option> is followed by any other character, it
      causes an abort.</para>

      <para>If the file name specifies a relative file name, it is put
      in the program's initial working directory : this is the current
      directory when the program started its execution after the fork
      or after the exec.  If it specifies an absolute file name (ie.
      starts with '/') then it is put there.
      </para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.log-socket" xreflabel="--log-socket">
    <term>
      <option><![CDATA[--log-socket=<ip-address:port-number> ]]></option>
    </term>
    <listitem>
      <para>Specifies that Valgrind should send all of its messages to
      the specified port at the specified IP address.  The port may be
      omitted, in which case port 1500 is used.  If a connection cannot
      be made to the specified socket, Valgrind falls back to writing
      output to the standard error (stderr).  This option is intended to
      be used in conjunction with the
      <computeroutput>valgrind-listener</computeroutput> program.  For
      further details, see 
      <link linkend="&vg-comment-id;">the commentary</link>
      in the manual.</para>
    </listitem>
  </varlistentry>

</variablelist>
<!-- end of xi:include in the manpage -->

</sect2>


<sect2 id="manual-core.erropts" xreflabel="Error-related Options">
<title>Error-related Options</title>

<!-- start of xi:include in the manpage -->
<para id="error-related.opts.para">These options are used by all tools
that can report errors, e.g. Memcheck, but not Cachegrind.</para>

<variablelist id="error-related.opts.list">

  <varlistentry id="opt.xml" xreflabel="--xml">
    <term>
      <option><![CDATA[--xml=<yes|no> [default: no] ]]></option>
    </term>
    <listitem>
      <para>When enabled, the important parts of the output (e.g. tool error
      messages) will be in XML format rather than plain text.  Furthermore,
      the XML output will be sent to a different output channel than the
      plain text output.  Therefore, you also must use one of
      <option>--xml-fd</option>, <option>--xml-file</option> or
      <option>--xml-socket</option> to specify where the XML is to be sent.
      </para>
      
      <para>Less important messages will still be printed in plain text, but
      because the XML output and plain text output are sent to different
      output channels (the destination of the plain text output is still
      controlled by <option>--log-fd</option>, <option>--log-file</option>
      and <option>--log-socket</option>) this should not cause problems.
      </para>

      <para>This option is aimed at making life easier for tools that consume
      Valgrind's output as input, such as GUI front ends.  Currently this
      option works with Memcheck, Helgrind, DRD and SGcheck.  The output
      format is specified in the file
      <computeroutput>docs/internals/xml-output-protocol4.txt</computeroutput>
      in the source tree for Valgrind 3.5.0 or later.</para>

      <para>The recommended options for a GUI to pass, when requesting
      XML output, are: <option>--xml=yes</option> to enable XML output,
      <option>--xml-file</option> to send the XML output to a (presumably
      GUI-selected) file, <option>--log-file</option> to send the plain
      text output to a second GUI-selected file,
      <option>--child-silent-after-fork=yes</option>, and
      <option>-q</option> to restrict the plain text output to critical
      error messages created by Valgrind itself.  For example, failure to
      read a specified suppressions file counts as a critical error message.
      In this way, for a successful run the text output file will be empty.
      But if it isn't empty, then it will contain important information
      which the GUI user should be made aware
      of.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.xml-fd" xreflabel="--xml-fd">
    <term>
      <option><![CDATA[--xml-fd=<number> [default: -1, disabled] ]]></option>
    </term>
    <listitem>
      <para>Specifies that Valgrind should send its XML output to the
      specified file descriptor.  It must be used in conjunction with
      <option>--xml=yes</option>.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.xml-file" xreflabel="--xml-file">
    <term>
      <option><![CDATA[--xml-file=<filename> ]]></option>
    </term>
    <listitem>
      <para>Specifies that Valgrind should send its XML output
      to the specified file.  It must be used in conjunction with
      <option>--xml=yes</option>.  Any <option>%p</option> or
      <option>%q</option> sequences appearing in the filename are expanded
      in exactly the same way as they are for <option>--log-file</option>.
      See the description of <option>--log-file</option> for details.
      </para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.xml-socket" xreflabel="--xml-socket">
    <term>
      <option><![CDATA[--xml-socket=<ip-address:port-number> ]]></option>
    </term>
    <listitem>
      <para>Specifies that Valgrind should send its XML output the
      specified port at the specified IP address.  It must be used in
      conjunction with <option>--xml=yes</option>.  The form of the argument
      is the same as that used by <option>--log-socket</option>.
      See the description of <option>--log-socket</option>
      for further details.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.xml-user-comment" xreflabel="--xml-user-comment">
    <term>
      <option><![CDATA[--xml-user-comment=<string> ]]></option>
    </term>
    <listitem>
      <para>Embeds an extra user comment string at the start of the XML
      output.  Only works when <option>--xml=yes</option> is specified;
      ignored otherwise.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.demangle" xreflabel="--demangle">
    <term>
      <option><![CDATA[--demangle=<yes|no> [default: yes] ]]></option>
    </term>
    <listitem>
      <para>Enable/disable automatic demangling (decoding) of C++ names.
      Enabled by default.  When enabled, Valgrind will attempt to
      translate encoded C++ names back to something approaching the
      original.  The demangler handles symbols mangled by g++ versions
      2.X, 3.X and 4.X.</para>

      <para>An important fact about demangling is that function names
      mentioned in suppressions files should be in their mangled form.
      Valgrind does not demangle function names when searching for
      applicable suppressions, because to do otherwise would make
      suppression file contents dependent on the state of Valgrind's
      demangling machinery, and also slow down suppression matching.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.num-callers" xreflabel="--num-callers">
    <term>
      <option><![CDATA[--num-callers=<number> [default: 12] ]]></option>
    </term>
    <listitem>
      <para>Specifies the maximum number of entries shown in stack traces
      that identify program locations.  Note that errors are commoned up
      using only the top four function locations (the place in the current
      function, and that of its three immediate callers).  So this doesn't
      affect the total number of errors reported.</para>

      <para>The maximum value for this is 500. Note that higher settings
      will make Valgrind run a bit more slowly and take a bit more
      memory, but can be useful when working with programs with
      deeply-nested call chains.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.unw-stack-scan-thresh"
                xreflabel="--unw-stack-scan-thresh">
    <term>
      <option><![CDATA[--unw-stack-scan-thresh=<number> [default: 0] ]]></option>
    </term>
    <term>
      <option><![CDATA[--unw-stack-scan-frames=<number> [default: 5] ]]></option>
    </term>
    <listitem>
      <para>Stack-scanning support is available only on ARM
      targets.</para>

      <para>These flags enable and control stack unwinding by stack
      scanning.  When the normal stack unwinding mechanisms -- usage
      of Dwarf CFI records, and frame-pointer following -- fail, stack
      scanning may be able to recover a stack trace.</para>

      <para>Note that stack scanning is an imprecise, heuristic
      mechanism that may give very misleading results, or none at all.
      It should be used only in emergencies, when normal unwinding
      fails, and it is important to nevertheless have stack
      traces.</para>

      <para>Stack scanning is a simple technique: the unwinder reads
      words from the stack, and tries to guess which of them might be
      return addresses, by checking to see if they point just after
      ARM or Thumb call instructions.  If so, the word is added to the
      backtrace.</para>

      <para>The main danger occurs when a function call returns,
      leaving its return address exposed, and a new function is
      called, but the new function does not overwrite the old address.
      The result of this is that the backtrace may contain entries for
      functions which have already returned, and so be very
      confusing.</para>

      <para>A second limitation of this implementation is that it will
      scan only the page (4KB, normally) containing the starting stack
      pointer.  If the stack frames are large, this may result in only
      a few (or not even any) being present in the trace.  Also, if
      you are unlucky and have an initial stack pointer near the end
      of its containing page, the scan may miss all interesting
      frames.</para>

      <para>By default stack scanning is disabled.  The normal use
      case is to ask for it when a stack trace would otherwise be very
      short.  So, to enable it,
      use <computeroutput>--unw-stack-scan-thresh=number</computeroutput>.
      This requests Valgrind to try using stack scanning to "extend"
      stack traces which contain fewer
      than <computeroutput>number</computeroutput> frames.</para>

      <para>If stack scanning does take place, it will only generate
      at most the number of frames specified
      by <computeroutput>--unw-stack-scan-frames</computeroutput>.
      Typically, stack scanning generates so many garbage entries that
      this value is set to a low value (5) by default.  In no case
      will a stack trace larger than the value specified
      by <computeroutput>--num-callers</computeroutput> be
      created.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.error-limit" xreflabel="--error-limit">
    <term>
      <option><![CDATA[--error-limit=<yes|no> [default: yes] ]]></option>
    </term>
    <listitem>
      <para>When enabled, Valgrind stops reporting errors after 10,000,000
      in total, or 1,000 different ones, have been seen.  This is to
      stop the error tracking machinery from becoming a huge performance
      overhead in programs with many errors.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.error-exitcode" xreflabel="--error-exitcode">
    <term>
      <option><![CDATA[--error-exitcode=<number> [default: 0] ]]></option>
    </term>
    <listitem>
      <para>Specifies an alternative exit code to return if Valgrind
      reported any errors in the run.  When set to the default value
      (zero), the return value from Valgrind will always be the return 
      value of the process being simulated.  When set to a nonzero value,
      that value is returned instead, if Valgrind detects any errors.
      This is useful for using Valgrind as part of an automated test
      suite, since it makes it easy to detect test cases for which
      Valgrind has reported errors, just by inspecting return codes.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.error-markers" xreflabel="--error-markers">
    <term>
      <option><![CDATA[--error-markers=<begin>,<end> [default: none]]]></option>
    </term>
    <listitem>
      <para>When errors are output as plain text (i.e. XML not used),
      <option>--error-markers</option> instructs to output a line
      containing the <option>begin</option> (<option>end</option>)
      string before (after) each error. </para>
      <para> Such marker lines facilitate searching for errors and/or
      extracting errors in an output file that contain valgrind errors mixed
      with the program output. </para>
      <para> Note that empty markers are accepted. So, only using a begin
      (or an end) marker is possible.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.sigill-diagnostics" xreflabel="--sigill-diagnostics">
    <term>
      <option><![CDATA[--sigill-diagnostics=<yes|no> [default: yes] ]]></option>
    </term>
    <listitem>
      <para>Enable/disable printing of illegal instruction diagnostics.
      Enabled by default, but defaults to disabled when
      <option>--quiet</option> is given. The default can always be explicitly
      overridden by giving this option.</para>

      <para>When enabled, a warning message will be printed, along with some
      diagnostics, whenever an instruction is encountered that Valgrind
      cannot decode or translate, before the program is given a SIGILL signal.
      Often an illegal instruction indicates a bug in the program or missing
      support for the particular instruction in Valgrind.  But some programs
      do deliberately try to execute an instruction that might be missing
      and trap the SIGILL signal to detect processor features.  Using
      this flag makes it possible to avoid the diagnostic output
      that you would otherwise get in such cases.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.show-below-main" xreflabel="--show-below-main">
    <term>
      <option><![CDATA[--show-below-main=<yes|no> [default: no] ]]></option>
    </term>
    <listitem>
      <para>By default, stack traces for errors do not show any
      functions that appear beneath <function>main</function> because
      most of the time it's uninteresting C library stuff and/or
      gobbledygook.  Alternatively, if <function>main</function> is not
      present in the stack trace, stack traces will not show any functions
      below <function>main</function>-like functions such as glibc's
      <function>__libc_start_main</function>.   Furthermore, if
      <function>main</function>-like functions are present in the trace,
      they are normalised as <function>(below main)</function>, in order to
      make the output more deterministic.</para>
      
      <para>If this option is enabled, all stack trace entries will be
      shown and <function>main</function>-like functions will not be
      normalised.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.fullpath-after" xreflabel="--fullpath-after">
    <term>
      <option><![CDATA[--fullpath-after=<string>
              [default: don't show source paths] ]]></option>
    </term>
    <listitem>
      <para>By default Valgrind only shows the filenames in stack
      traces, but not full paths to source files.  When using Valgrind
      in large projects where the sources reside in multiple different
      directories, this can be inconvenient.
      <option>--fullpath-after</option> provides a flexible solution
      to this problem.  When this option is present, the path to each
      source file is shown, with the following all-important caveat:
      if <option>string</option> is found in the path, then the path
      up to and including <option>string</option> is omitted, else the
      path is shown unmodified.  Note that <option>string</option> is
      not required to be a prefix of the path.</para>

      <para>For example, consider a file named
      <computeroutput>/home/janedoe/blah/src/foo/bar/xyzzy.c</computeroutput>.
      Specifying <option>--fullpath-after=/home/janedoe/blah/src/</option>
      will cause Valgrind to show the name
      as <computeroutput>foo/bar/xyzzy.c</computeroutput>.</para>

      <para>Because the string is not required to be a prefix,
      <option>--fullpath-after=src/</option> will produce the same
      output.  This is useful when the path contains arbitrary
      machine-generated characters.  For example, the
      path
      <computeroutput>/my/build/dir/C32A1B47/blah/src/foo/xyzzy</computeroutput>
      can be pruned to <computeroutput>foo/xyzzy</computeroutput>
      using
      <option>--fullpath-after=/blah/src/</option>.</para>

      <para>If you simply want to see the full path, just specify an
      empty string: <option>--fullpath-after=</option>.  This isn't a
      special case, merely a logical consequence of the above rules.</para>

      <para>Finally, you can use <option>--fullpath-after</option>
      multiple times.  Any appearance of it causes Valgrind to switch
      to producing full paths and applying the above filtering rule.
      Each produced path is compared against all
      the <option>--fullpath-after</option>-specified strings, in the
      order specified.  The first string to match causes the path to
      be truncated as described above.  If none match, the full path
      is shown.  This facilitates chopping off prefixes when the
      sources are drawn from a number of unrelated directories.
      </para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.extra-debuginfo-path" xreflabel="--extra-debuginfo-path">
    <term>
      <option><![CDATA[--extra-debuginfo-path=<path> [default: undefined and unused] ]]></option>
    </term>
    <listitem>
      <para>By default Valgrind searches in several well-known paths
      for debug objects, such
      as <computeroutput>/usr/lib/debug/</computeroutput>.</para>

      <para>However, there may be scenarios where you may wish to put
      debug objects at an arbitrary location, such as external storage
      when running Valgrind on a mobile device with limited local
      storage.  Another example might be a situation where you do not
      have permission to install debug object packages on the system
      where you are running Valgrind.</para>

      <para>In these scenarios, you may provide an absolute path as an extra,
      final place for Valgrind to search for debug objects by specifying
      <option>--extra-debuginfo-path=/path/to/debug/objects</option>.
      The given path will be prepended to the absolute path name of
      the searched-for object.  For example, if Valgrind is looking
      for the debuginfo
      for <computeroutput>/w/x/y/zz.so</computeroutput>
      and <option>--extra-debuginfo-path=/a/b/c</option> is specified,
      it will look for a debug object at
      <computeroutput>/a/b/c/w/x/y/zz.so</computeroutput>.</para>

      <para>This flag should only be specified once.  If it is
      specified multiple times, only the last instance is
      honoured.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.debuginfo-server" xreflabel="--debuginfo-server">
    <term>
      <option><![CDATA[--debuginfo-server=ipaddr:port [default: undefined and unused]]]></option>
    </term>
    <listitem>
      <para>This is a new, experimental, feature introduced in version
      3.9.0.</para>

      <para>In some scenarios it may be convenient to read debuginfo
      from objects stored on a different machine.  With this flag,
      Valgrind will query a debuginfo server running
      on <computeroutput>ipaddr</computeroutput> and listening on
      port <computeroutput>port</computeroutput>, if it cannot find
      the debuginfo object in the local filesystem.</para>

      <para>The debuginfo server must accept TCP connections on
      port <computeroutput>port</computeroutput>.  The debuginfo
      server is contained in the source
      file <computeroutput>auxprogs/valgrind-di-server.c</computeroutput>.
      It will only serve from the directory it is started
      in.  <computeroutput>port</computeroutput> defaults to 1500 in
      both client and server if not specified.</para>

      <para>If Valgrind looks for the debuginfo for
      <computeroutput>/w/x/y/zz.so</computeroutput> by using the
      debuginfo server, it will strip the pathname components and
      merely request <computeroutput>zz.so</computeroutput> on the
      server.  That in turn will look only in its current working
      directory for a matching debuginfo object.</para>

      <para>The debuginfo data is transmitted in small fragments (8
      KB) as requested by Valgrind.  Each block is compressed using
      LZO to reduce transmission time.  The implementation has been
      tuned for best performance over a single-stage 802.11g (WiFi)
      network link.</para>

      <para>Note that checks for matching primary vs debug objects,
      using GNU debuglink CRC scheme, are performed even when using
      the debuginfo server.  To disable such checking, you need to
      also specify
      <computeroutput>--allow-mismatched-debuginfo=yes</computeroutput>.
      </para>

      <para>By default the Valgrind build system will
      build <computeroutput>valgrind-di-server</computeroutput> for
      the target platform, which is almost certainly not what you
      want.  So far we have been unable to find out how to get
      automake/autoconf to build it for the build platform.  If
      you want to use it, you will have to recompile it by hand using
      the command shown at the top
      of <computeroutput>auxprogs/valgrind-di-server.c</computeroutput>.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.allow-mismatched-debuginfo"
                xreflabel="--allow-mismatched-debuginfo">
    <term>
      <option><![CDATA[--allow-mismatched-debuginfo=no|yes [no] ]]></option>
    </term>
    <listitem>
      <para>When reading debuginfo from separate debuginfo objects,
      Valgrind will by default check that the main and debuginfo
      objects match, using the GNU debuglink mechanism.  This
      guarantees that it does not read debuginfo from out of date
      debuginfo objects, and also ensures that Valgrind can't crash as
      a result of mismatches.</para>

      <para>This check can be overridden using 
      <computeroutput>--allow-mismatched-debuginfo=yes</computeroutput>.
      This may be useful when the debuginfo and main objects have not
      been split in the proper way.  Be careful when using this,
      though: it disables all consistency checking, and Valgrind has
      been observed to crash when the main and debuginfo objects don't
      match.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.suppressions" xreflabel="--suppressions">
    <term>
      <option><![CDATA[--suppressions=<filename> [default: $PREFIX/lib/valgrind/default.supp] ]]></option>
    </term>
    <listitem>
      <para>Specifies an extra file from which to read descriptions of
      errors to suppress.  You may use up to 100 extra suppression
      files.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.gen-suppressions" xreflabel="--gen-suppressions">
    <term>
      <option><![CDATA[--gen-suppressions=<yes|no|all> [default: no] ]]></option>
    </term>
    <listitem>
      <para>When set to <varname>yes</varname>, Valgrind will pause
      after every error shown and print the line:
      <literallayout><computeroutput>    ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----</computeroutput></literallayout>

      Pressing <varname>Ret</varname>, or <varname>N Ret</varname> or
      <varname>n Ret</varname>, causes Valgrind continue execution without
      printing a suppression for this error.</para>

      <para>Pressing <varname>Y Ret</varname> or
      <varname>y Ret</varname> causes Valgrind to write a suppression
      for this error.  You can then cut and paste it into a suppression file
      if you don't want to hear about the error in the future.</para>

      <para>When set to <varname>all</varname>, Valgrind will print a
      suppression for every reported error, without querying the
      user.</para>

      <para>This option is particularly useful with C++ programs, as it
      prints out the suppressions with mangled names, as
      required.</para>

      <para>Note that the suppressions printed are as specific as
      possible.  You may want to common up similar ones, by adding
      wildcards to function names, and by using frame-level wildcards.
      The wildcarding facilities are powerful yet flexible, and with a
      bit of careful editing, you may be able to suppress a whole
      family of related errors with only a few suppressions.  
      <!-- commented out because it causes broken links in the man page
      For details on how to do this, see
      <xref linkend="manual-core.suppress"/>.
      -->
      </para>

      <para>Sometimes two different errors
      are suppressed by the same suppression, in which case Valgrind
      will output the suppression more than once, but you only need to
      have one copy in your suppression file (but having more than one
      won't cause problems).  Also, the suppression name is given as
      <computeroutput>&lt;insert a suppression name
      here&gt;</computeroutput>; the name doesn't really matter, it's
      only used with the <option>-v</option> option which prints out all
      used suppression records.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.input-fd" xreflabel="--input-fd">
    <term>
      <option><![CDATA[--input-fd=<number> [default: 0, stdin] ]]></option>
    </term>
    <listitem>
      <para>When using
      <option>--gen-suppressions=yes</option>, Valgrind will stop so as
      to read keyboard input from you when each error occurs.  By
      default it reads from the standard input (stdin), which is
      problematic for programs which close stdin.  This option allows
      you to specify an alternative file descriptor from which to read
      input.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.dsymutil" xreflabel="--dsymutil">
    <term>
      <option><![CDATA[--dsymutil=no|yes [yes] ]]></option>
    </term>
    <listitem>
      <para>This option is only relevant when running Valgrind on
      Mac OS X.</para>

      <para>Mac OS X uses a deferred debug information (debuginfo)
      linking scheme.  When object files containing debuginfo are
      linked into a <computeroutput>.dylib</computeroutput> or an
      executable, the debuginfo is not copied into the final file.
      Instead, the debuginfo must be linked manually by
      running <computeroutput>dsymutil</computeroutput>, a
      system-provided utility, on the executable
      or <computeroutput>.dylib</computeroutput>.  The resulting
      combined debuginfo is placed in a directory alongside the
      executable or <computeroutput>.dylib</computeroutput>, but with
      the extension <computeroutput>.dSYM</computeroutput>.</para>

      <para>With <option>--dsymutil=no</option>, Valgrind
      will detect cases where the
      <computeroutput>.dSYM</computeroutput> directory is either
      missing, or is present but does not appear to match the
      associated executable or <computeroutput>.dylib</computeroutput>,
      most likely because it is out of date.  In these cases, Valgrind
      will print a warning message but take no further action.</para>

      <para>With <option>--dsymutil=yes</option>, Valgrind
      will, in such cases, automatically
      run <computeroutput>dsymutil</computeroutput> as necessary to
      bring the debuginfo up to date.  For all practical purposes, if
      you always use <option>--dsymutil=yes</option>, then
      there is never any need to
      run <computeroutput>dsymutil</computeroutput> manually or as part
      of your applications's build system, since Valgrind will run it
      as necessary.</para>

      <para>Valgrind will not attempt to
      run <computeroutput>dsymutil</computeroutput> on any 
      executable or library in
      <computeroutput>/usr/</computeroutput>,
      <computeroutput>/bin/</computeroutput>,
      <computeroutput>/sbin/</computeroutput>,
      <computeroutput>/opt/</computeroutput>,
      <computeroutput>/sw/</computeroutput>,
      <computeroutput>/System/</computeroutput>,
      <computeroutput>/Library/</computeroutput> or
      <computeroutput>/Applications/</computeroutput>
      since <computeroutput>dsymutil</computeroutput> will always fail
      in such situations.  It fails both because the debuginfo for
      such pre-installed system components is not available anywhere,
      and also because it would require write privileges in those
      directories.</para>

      <para>Be careful when
      using <option>--dsymutil=yes</option>, since it will
      cause pre-existing <computeroutput>.dSYM</computeroutput>
      directories to be silently deleted and re-created.  Also note that
      <computeroutput>dsymutil</computeroutput> is quite slow, sometimes
      excessively so.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.max-stackframe" xreflabel="--max-stackframe">
    <term>
      <option><![CDATA[--max-stackframe=<number> [default: 2000000] ]]></option>
    </term>
    <listitem>
      <para>The maximum size of a stack frame.  If the stack pointer moves by
      more than this amount then Valgrind will assume that
      the program is switching to a different stack.</para>

      <para>You may need to use this option if your program has large
      stack-allocated arrays.  Valgrind keeps track of your program's
      stack pointer.  If it changes by more than the threshold amount,
      Valgrind assumes your program is switching to a different stack,
      and Memcheck behaves differently than it would for a stack pointer
      change smaller than the threshold.  Usually this heuristic works
      well.  However, if your program allocates large structures on the
      stack, this heuristic will be fooled, and Memcheck will
      subsequently report large numbers of invalid stack accesses.  This
      option allows you to change the threshold to a different
      value.</para>

      <para>You should only consider use of this option if Valgrind's
      debug output directs you to do so.  In that case it will tell you
      the new threshold you should specify.</para>

      <para>In general, allocating large structures on the stack is a
      bad idea, because you can easily run out of stack space,
      especially on systems with limited memory or which expect to
      support large numbers of threads each with a small stack, and also
      because the error checking performed by Memcheck is more effective
      for heap-allocated data than for stack-allocated data.  If you
      have to use this option, you may wish to consider rewriting your
      code to allocate on the heap rather than on the stack.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.main-stacksize" xreflabel="--main-stacksize">
    <term>
      <option><![CDATA[--main-stacksize=<number>
               [default: use current 'ulimit' value] ]]></option>
    </term>
    <listitem>
      <para>Specifies the size of the main thread's stack.</para>

      <para>To simplify its memory management, Valgrind reserves all
      required space for the main thread's stack at startup.  That
      means it needs to know the required stack size at
      startup.</para>

      <para>By default, Valgrind uses the current "ulimit" value for
      the stack size, or 16 MB, whichever is lower.  In many cases
      this gives a stack size in the range 8 to 16 MB, which almost
      never overflows for most applications.</para>

      <para>If you need a larger total stack size,
      use <option>--main-stacksize</option> to specify it.  Only set
      it as high as you need, since reserving far more space than you
      need (that is, hundreds of megabytes more than you need)
      constrains Valgrind's memory allocators and may reduce the total
      amount of memory that Valgrind can use.  This is only really of
      significance on 32-bit machines.</para>

      <para>On Linux, you may request a stack of size up to 2GB.
      Valgrind will stop with a diagnostic message if the stack cannot
      be allocated.</para>

      <para><option>--main-stacksize</option> only affects the stack
      size for the program's initial thread.  It has no bearing on the
      size of thread stacks, as Valgrind does not allocate
      those.</para>

      <para>You may need to use both <option>--main-stacksize</option>
      and <option>--max-stackframe</option> together.  It is important
      to understand that <option>--main-stacksize</option> sets the
      maximum total stack size,
      whilst <option>--max-stackframe</option> specifies the largest
      size of any one stack frame.  You will have to work out
      the <option>--main-stacksize</option> value for yourself
      (usually, if your applications segfaults).  But Valgrind will
      tell you the needed <option>--max-stackframe</option> size, if
      necessary.</para>

      <para>As discussed further in the description
      of <option>--max-stackframe</option>, a requirement for a large
      stack is a sign of potential portability problems.  You are best
      advised to place all large data in heap-allocated memory.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.max-threads" xreflabel="--max-threads">
    <term>
      <option><![CDATA[--max-threads=<number> [default: 500] ]]></option>
    </term>
    <listitem>
      <para>By default, Valgrind can handle to up to 500 threads.
      Occasionally, that number is too small. Use this option to
      provide a different limit. E.g.
      <computeroutput>--max-threads=3000</computeroutput>.
      </para>
    </listitem>
  </varlistentry>

</variablelist>
<!-- end of xi:include in the manpage -->

</sect2>


<sect2 id="manual-core.mallocopts" xreflabel="malloc-related Options">
<title>malloc-related Options</title>

<!-- start of xi:include in the manpage -->
<para id="malloc-related.opts.para">For tools that use their own version of
<computeroutput>malloc</computeroutput> (e.g. Memcheck,
Massif, Helgrind, DRD), the following options apply.</para>

<variablelist id="malloc-related.opts.list">

  <varlistentry id="opt.alignment" xreflabel="--alignment">
    <term>
      <option><![CDATA[--alignment=<number> [default: 8 or 16, depending on the platform] ]]></option>
    </term>
    <listitem>
      <para>By default Valgrind's <function>malloc</function>,
      <function>realloc</function>, etc, return a block whose starting
      address is 8-byte aligned or 16-byte aligned (the value depends on the
      platform and matches the platform default).  This option allows you to
      specify a different alignment.  The supplied value must be greater
      than or equal to the default, less than or equal to 4096, and must be
      a power of two.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.redzone-size" xreflabel="--redzone-size">
    <term>
      <option><![CDATA[--redzone-size=<number> [default: depends on the tool] ]]></option>
    </term>
    <listitem>
      <para> Valgrind's <function>malloc, realloc,</function> etc, add
      padding blocks before and after each heap block allocated by the
      program being run. Such padding blocks are called redzones.  The
      default value for the redzone size depends on the tool.  For
      example, Memcheck adds and protects a minimum of 16 bytes before
      and after each block allocated by the client.  This allows it to
      detect block underruns or overruns of up to 16 bytes.
      </para>
      <para>Increasing the redzone size makes it possible to detect
      overruns of larger distances, but increases the amount of memory
      used by Valgrind.  Decreasing the redzone size will reduce the
      memory needed by Valgrind but also reduces the chances of
      detecting over/underruns, so is not recommended.</para>
    </listitem>
  </varlistentry>

</variablelist>
<!-- end of xi:include in the manpage -->

</sect2>


<sect2 id="manual-core.rareopts" xreflabel="Uncommon Options">
<title>Uncommon Options</title>

<!-- start of xi:include in the manpage -->
<para id="uncommon.opts.para">These options apply to all tools, as they
affect certain obscure workings of the Valgrind core.  Most people won't
need to use them.</para>

<variablelist id="uncommon.opts.list">

  <varlistentry id="opt.smc-check" xreflabel="--smc-check">
    <term>
      <option><![CDATA[--smc-check=<none|stack|all|all-non-file>
      [default: all-non-file for x86/amd64/s390x, stack for other archs] ]]></option>
    </term>
    <listitem>
      <para>This option controls Valgrind's detection of self-modifying
       code.  If no checking is done, when a program executes some code, then
       overwrites it with new code, and executes the new code, Valgrind will
       continue to execute the translations it made for the old code.  This
       will likely lead to incorrect behaviour and/or crashes.</para>
      <para>For "modern" architectures -- anything that's not x86,
        amd64 or s390x -- the default is <varname>stack</varname>.
        This is because a correct program must take explicit action
        to reestablish D-I cache coherence following code
        modification.  Valgrind observes and honours such actions,
        with the result that self-modifying code is transparently
        handled with zero extra cost.</para>
       <para>For x86, amd64 and s390x, the program is not required to
        notify the hardware of required D-I coherence syncing.  Hence
        the default is <varname>all-non-file</varname>, which covers
        the normal case of generating code into an anonymous
        (non-file-backed) mmap'd area.</para>
       <para>The meanings of the four available settings are as
        follows.  No detection (<varname>none</varname>),
        detect self-modifying code
        on the stack (which is used by GCC to implement nested
        functions) (<varname>stack</varname>), detect self-modifying code
        everywhere (<varname>all</varname>), and detect
        self-modifying code everywhere except in file-backed
        mappings (<varname>all-non-file</varname>).</para>
       <para>Running with <varname>all</varname> will slow Valgrind
        down noticeably.  Running with <varname>none</varname> will
        rarely speed things up, since very little code gets
        dynamically generated in most programs.  The
        <function>VALGRIND_DISCARD_TRANSLATIONS</function> client
        request is an alternative to <option>--smc-check=all</option>
        and <option>--smc-check=all-non-file</option>
        that requires more programmer effort but allows Valgrind to run
        your program faster, by telling it precisely when translations
        need to be re-made.
        <!-- commented out because it causes broken links in the man page
        ;  see <xref
        linkend="manual-core-adv.clientreq"/> for more details.
        -->
        </para>
      <para><option>--smc-check=all-non-file</option> provides a
       cheaper but more limited version
       of <option>--smc-check=all</option>.  It adds checks to any
       translations that do not originate from file-backed memory
       mappings.  Typical applications that generate code, for example
       JITs in web browsers, generate code into anonymous mmaped areas,
       whereas the "fixed" code of the browser always lives in
       file-backed mappings.  <option>--smc-check=all-non-file</option>
       takes advantage of this observation, limiting the overhead of
       checking to code which is likely to be JIT generated.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.read-inline-info" xreflabel="--read-inline-info">
    <term>
      <option><![CDATA[--read-inline-info=<yes|no> [default: see below] ]]></option>
    </term>
    <listitem>
      <para>When enabled, Valgrind will read information about inlined
      function calls from DWARF3 debug info.  This slows Valgrind
      startup and makes it use more memory (typically for each inlined
      piece of code, 6 words and space for the function name), but it
      results in more descriptive stacktraces.  For the 3.10.0
      release, this functionality is enabled by default only for Linux,
      Android and Solaris targets and only for the tools Memcheck, Helgrind
      and DRD.  Here is an example of some stacktraces with
      <option>--read-inline-info=no</option>:
</para>
<programlisting><![CDATA[
==15380== Conditional jump or move depends on uninitialised value(s)
==15380==    at 0x80484EA: main (inlinfo.c:6)
==15380== 
==15380== Conditional jump or move depends on uninitialised value(s)
==15380==    at 0x8048550: fun_noninline (inlinfo.c:6)
==15380==    by 0x804850E: main (inlinfo.c:34)
==15380== 
==15380== Conditional jump or move depends on uninitialised value(s)
==15380==    at 0x8048520: main (inlinfo.c:6)
]]></programlisting>
      <para>And here are the same errors with
      <option>--read-inline-info=yes</option>:</para>
<programlisting><![CDATA[
==15377== Conditional jump or move depends on uninitialised value(s)
==15377==    at 0x80484EA: fun_d (inlinfo.c:6)
==15377==    by 0x80484EA: fun_c (inlinfo.c:14)
==15377==    by 0x80484EA: fun_b (inlinfo.c:20)
==15377==    by 0x80484EA: fun_a (inlinfo.c:26)
==15377==    by 0x80484EA: main (inlinfo.c:33)
==15377== 
==15377== Conditional jump or move depends on uninitialised value(s)
==15377==    at 0x8048550: fun_d (inlinfo.c:6)
==15377==    by 0x8048550: fun_noninline (inlinfo.c:41)
==15377==    by 0x804850E: main (inlinfo.c:34)
==15377== 
==15377== Conditional jump or move depends on uninitialised value(s)
==15377==    at 0x8048520: fun_d (inlinfo.c:6)
==15377==    by 0x8048520: main (inlinfo.c:35)
]]></programlisting>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.read-var-info" xreflabel="--read-var-info">
    <term>
      <option><![CDATA[--read-var-info=<yes|no> [default: no] ]]></option>
    </term>
    <listitem>
      <para>When enabled, Valgrind will read information about
      variable types and locations from DWARF3 debug info.
      This slows Valgrind startup significantly and makes it use significantly
      more memory, but for the tools that can take advantage of it (Memcheck,
      Helgrind, DRD) it can result in more precise error messages.  For example,
      here are some standard errors issued by Memcheck:</para>
<programlisting><![CDATA[
==15363== Uninitialised byte(s) found during client check request
==15363==    at 0x80484A9: croak (varinfo1.c:28)
==15363==    by 0x8048544: main (varinfo1.c:55)
==15363==  Address 0x80497f7 is 7 bytes inside data symbol "global_i2"
==15363== 
==15363== Uninitialised byte(s) found during client check request
==15363==    at 0x80484A9: croak (varinfo1.c:28)
==15363==    by 0x8048550: main (varinfo1.c:56)
==15363==  Address 0xbea0d0cc is on thread 1's stack
==15363==  in frame #1, created by main (varinfo1.c:45)
]]></programlisting>

      <para>And here are the same errors with
      <option>--read-var-info=yes</option>:</para>

<programlisting><![CDATA[
==15370== Uninitialised byte(s) found during client check request
==15370==    at 0x80484A9: croak (varinfo1.c:28)
==15370==    by 0x8048544: main (varinfo1.c:55)
==15370==  Location 0x80497f7 is 0 bytes inside global_i2[7],
==15370==  a global variable declared at varinfo1.c:41
==15370== 
==15370== Uninitialised byte(s) found during client check request
==15370==    at 0x80484A9: croak (varinfo1.c:28)
==15370==    by 0x8048550: main (varinfo1.c:56)
==15370==  Location 0xbeb4a0cc is 0 bytes inside local var "local"
==15370==  declared at varinfo1.c:46, in frame #1 of thread 1
]]></programlisting>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.vgdb-poll" xreflabel="--vgdb-poll">
    <term>
      <option><![CDATA[--vgdb-poll=<number> [default: 5000] ]]></option>
    </term>
    <listitem>
      <para> As part of its main loop, the Valgrind scheduler will
      poll to check if some activity (such as an external command or
      some input from a gdb) has to be handled by gdbserver.  This
      activity poll will be done after having run the given number of
      basic blocks (or slightly more than the given number of basic
      blocks). This poll is quite cheap so the default value is set
      relatively low. You might further decrease this value if vgdb
      cannot use ptrace system call to interrupt Valgrind if all
      threads are (most of the time) blocked in a system call.
      </para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.vgdb-shadow-registers" xreflabel="--vgdb-shadow-registers">
    <term>
      <option><![CDATA[--vgdb-shadow-registers=no|yes [default: no] ]]></option>
    </term>
    <listitem>
      <para> When activated, gdbserver will expose the Valgrind shadow registers
      to GDB. With this, the value of the Valgrind shadow registers can be examined
      or changed using GDB. Exposing shadow registers only works with GDB version
      7.1 or later.
      </para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.vgdb-prefix" xreflabel="--vgdb-prefix">
    <term>
      <option><![CDATA[--vgdb-prefix=<prefix> [default: /tmp/vgdb-pipe] ]]></option>
    </term>
    <listitem>
      <para> To communicate with gdb/vgdb, the Valgrind gdbserver
      creates 3 files (2 named FIFOs and a mmap shared memory
      file). The prefix option controls the directory and prefix for
      the creation of these files.
      </para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.run-libc-freeres" xreflabel="--run-libc-freeres">
    <term>
      <option><![CDATA[--run-libc-freeres=<yes|no> [default: yes] ]]></option>
    </term>
    <listitem>
      <para>This option is only relevant when running Valgrind on Linux.</para>

      <para>The GNU C library (<function>libc.so</function>), which is
      used by all programs, may allocate memory for its own uses.
      Usually it doesn't bother to free that memory when the program
      ends&mdash;there would be no point, since the Linux kernel reclaims
      all process resources when a process exits anyway, so it would
      just slow things down.</para>

      <para>The glibc authors realised that this behaviour causes leak
      checkers, such as Valgrind, to falsely report leaks in glibc, when
      a leak check is done at exit.  In order to avoid this, they
      provided a routine called <function>__libc_freeres</function>
      specifically to make glibc release all memory it has allocated.
      Memcheck therefore tries to run
      <function>__libc_freeres</function> at exit.</para>

      <para>Unfortunately, in some very old versions of glibc,
      <function>__libc_freeres</function> is sufficiently buggy to cause
      segmentation faults.  This was particularly noticeable on Red Hat
      7.1.  So this option is provided in order to inhibit the run of
      <function>__libc_freeres</function>.  If your program seems to run
      fine on Valgrind, but segfaults at exit, you may find that
      <option>--run-libc-freeres=no</option> fixes that, although at the
      cost of possibly falsely reporting space leaks in
      <filename>libc.so</filename>.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.run-cxx-freeres" xreflabel="--run-cxx-freeres">
    <term>
      <option><![CDATA[--run-cxx-freeres=<yes|no> [default: yes] ]]></option>
    </term>
    <listitem>
      <para>This option is only relevant when running Valgrind on Linux
            or Solaris C++ programs.</para>

      <para>The GNU Standard C++ library (<function>libstdc++.so</function>),
      which is used by all C++ programs compiled with g++, may allocate memory
      for its own uses. Usually it doesn't bother to free that memory when
      the program ends&mdash;there would be no point, since the kernel reclaims
      all process resources when a process exits anyway, so it would
      just slow things down.</para>

      <para>The gcc authors realised that this behaviour causes leak
      checkers, such as Valgrind, to falsely report leaks in libstdc++, when
      a leak check is done at exit.  In order to avoid this, they
      provided a routine called <function>__gnu_cxx::__freeres</function>
      specifically to make libstdc++ release all memory it has allocated.
      Memcheck therefore tries to run
      <function>__gnu_cxx::__freeres</function> at exit.</para>

      <para>For the sake of flexibility and unforeseen problems with
      <function>__gnu_cxx::__freeres</function>, option
      <option>--run-cxx-freeres=no</option> exists,
      although at the cost of possibly falsely reporting space leaks in
      <filename>libstdc++.so</filename>.</para>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.sim-hints" xreflabel="--sim-hints">
    <term>
      <option><![CDATA[--sim-hints=hint1,hint2,... ]]></option>
    </term>
    <listitem>
      <para>Pass miscellaneous hints to Valgrind which slightly modify
      the simulated behaviour in nonstandard or dangerous ways, possibly
      to help the simulation of strange features.  By default no hints
      are enabled.  Use with caution!  Currently known hints are:</para>

      <itemizedlist>
        <listitem>
          <para><option>lax-ioctls: </option> Be very lax about ioctl
          handling; the only assumption is that the size is
          correct. Doesn't require the full buffer to be initialised
          when writing.  Without this, using some device drivers with a
          large number of strange ioctl commands becomes very
          tiresome.</para>
        </listitem>

        <listitem>
          <para><option>fuse-compatible: </option> Enable special
            handling for certain system calls that may block in a FUSE
            file-system.  This may be necessary when running Valgrind
            on a multi-threaded program that uses one thread to manage
            a FUSE file-system and another thread to access that
            file-system.
          </para>
        </listitem>

        <listitem>
          <para><option>enable-outer: </option> Enable some special
          magic needed when the program being run is itself
          Valgrind.</para>
        </listitem>

        <listitem>
          <para><option>no-inner-prefix: </option> Disable printing
          a prefix <option>&gt;</option> in front of each stdout or
          stderr output line in an inner Valgrind being run by an
          outer Valgrind. This is useful when running Valgrind
          regression tests in an outer/inner setup. Note that the
          prefix <option>&gt;</option> will always be printed in
          front of the inner debug logging lines.</para>
        </listitem>
        <listitem>
          <para><option>no-nptl-pthread-stackcache: </option>
            This hint is only relevant when running Valgrind on Linux.</para>

          <para>The GNU glibc pthread library
            (<function>libpthread.so</function>), which is used by
            pthread programs, maintains a cache of pthread stacks.
            When a pthread terminates, the memory used for the pthread
            stack and some thread local storage related data structure
            are not always directly released.  This memory is kept in
            a cache (up to a certain size), and is re-used if a new
            thread is started.</para>

          <para>This cache causes the helgrind tool to report some
            false positive race condition errors on this cached
            memory, as helgrind does not understand the internal glibc
            cache synchronisation primitives. So, when using helgrind,
            disabling the cache helps to avoid false positive race
            conditions, in particular when using thread local storage
            variables (e.g. variables using the
            <function>__thread</function> qualifier).</para>

          <para>When using the memcheck tool, disabling the cache
            ensures the memory used by glibc to handle __thread
            variables is directly released when a thread
            terminates.</para>

          <para>Note: Valgrind disables the cache using some internal
            knowledge of the glibc stack cache implementation and by
            examining the debug information of the pthread
            library. This technique is thus somewhat fragile and might
            not work for all glibc versions. This has been successfully
            tested with various glibc versions (e.g. 2.11, 2.16, 2.18)
            on various platforms.</para>
        </listitem>
        <listitem>
          <para><option>lax-doors: </option> (Solaris only) Be very lax
          about door syscall handling over unrecognised door file
          descriptors. Does not require that full buffer is initialised
          when writing. Without this, programs using libdoor(3LIB)
          functionality with completely proprietary semantics may report
          large number of false positives.</para>
        </listitem>
      </itemizedlist>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.fair-sched" xreflabel="--fair-sched">
    <term>
      <option><![CDATA[--fair-sched=<no|yes|try>    [default: no] ]]></option>
    </term>

    <listitem> <para>The <option>--fair-sched</option> option controls
      the locking mechanism used by Valgrind to serialise thread
      execution.  The locking mechanism controls the way the threads
      are scheduled, and different settings give different trade-offs
      between fairness and performance. For more details about the
      Valgrind thread serialisation scheme and its impact on
      performance and thread scheduling, see
      <xref linkend="&vg-pthreads-perf-sched-id;"/>.</para>

      <itemizedlist>
        <listitem> <para>The value <option>--fair-sched=yes</option>
          activates a fair scheduler.  In short, if multiple threads are
          ready to run, the threads will be scheduled in a round robin
          fashion.  This mechanism is not available on all platforms or
          Linux versions.  If not available,
          using <option>--fair-sched=yes</option> will cause Valgrind to
          terminate with an error.</para>
        <para>You may find this setting improves overall
          responsiveness if you are running an interactive
          multithreaded program, for example a web browser, on
          Valgrind.</para>
        </listitem>
        
        <listitem> <para>The value <option>--fair-sched=try</option>
          activates fair scheduling if available on the
          platform.  Otherwise, it will automatically fall back
          to <option>--fair-sched=no</option>.</para>
        </listitem>
        
        <listitem> <para>The value <option>--fair-sched=no</option> activates
          a scheduler which does not guarantee fairness
          between threads ready to run, but which in general gives the
         highest performance.</para>
        </listitem>
      </itemizedlist>
    </listitem>

  </varlistentry>

  <varlistentry id="opt.kernel-variant" xreflabel="--kernel-variant">
    <term>
      <option>--kernel-variant=variant1,variant2,...</option>
    </term>
    <listitem>
      <para>Handle system calls and ioctls arising from minor variants
      of the default kernel for this platform.  This is useful for
      running on hacked kernels or with kernel modules which support
      nonstandard ioctls, for example.  Use with caution.  If you don't
      understand what this option does then you almost certainly don't
      need it.  Currently known variants are:</para>
      <itemizedlist>
        <listitem>
          <para><option>bproc</option>: support the
            <function>sys_broc</function> system call on x86.  This is for
            running on BProc, which is a minor variant of standard Linux which
            is sometimes used for building clusters.
          </para>
        </listitem>
        <listitem>
          <para><option>android-no-hw-tls</option>: some
          versions of the Android emulator for ARM do not provide a
          hardware TLS (thread-local state) register, and Valgrind
          crashes at startup.  Use this variant to select software
          support for TLS.
          </para>
        </listitem>
        <listitem>
          <para><option>android-gpu-sgx5xx</option>: use this to
          support handling of proprietary ioctls for the PowerVR SGX
          5XX series of GPUs on Android devices.  Failure to select
          this does not cause stability problems, but may cause
          Memcheck to report false errors after the program performs
          GPU-specific ioctls.
          </para>
        </listitem>
        <listitem>
          <para><option>android-gpu-adreno3xx</option>: similarly, use
          this to support handling of proprietary ioctls for the
          Qualcomm Adreno 3XX series of GPUs on Android devices.
          </para>
        </listitem>
      </itemizedlist>
    </listitem>
  </varlistentry>

  <varlistentry id="opt.merge-recursive-frames" xreflabel="--merge-recursive-frames">
    <term>
      <option><![CDATA[--merge-recursive-frames=<number> [default: 0] ]]></option>
    </term>
    <listitem>
      <para>Some recursive algorithms, for example balanced binary
      tree implementations, create many different stack traces, each
      containing cycles of calls.  A cycle is defined as two identical
      program counter values separated by zero or more other program
      counter values.  Valgrind may then use a lot of memory to store
      all these stack traces.  This is a poor use of memory
      considering that such stack traces contain repeated
      uninteresting recursive calls instead of more interesting
      information such as the function that has initiated the
      recursive call.
      </para>
      <para>The option <option>--merge-recursive-frames=&lt;number&gt;</option>
      instructs Valgrind to detect and merge recursive call cycles
      having a size of up to <option>&lt;number&gt;</option>
      frames. When such a cycle is detected, Valgrind records the
      cycle in the stack trace as a unique program counter.
      </para>
      <para>
      The value 0 (the default) causes no recursive call merging.
      A value of 1 will cause stack traces of simple recursive algorithms
      (for example, a factorial implementation) to be collapsed.
      A value of 2 will usually be needed to collapse stack traces produced
      by recursive algorithms such as binary trees, quick sort, etc.
      Higher values might be needed for more complex recursive algorithms.
      </para>
      <para>Note: recursive calls are detected by analysis of program
      counter values.  They are not detected by looking at function
      names.</para>
   </listitem>
  </varlistentry>

  <varlistentry id="opt.num-transtab-sectors" xreflabel="--num-transtab-sectors">
    <term>
      <option><![CDATA[--num-transtab-sectors=<number> [default: 6
      for Android platforms, 16 for all others] ]]></option>
    </term>
    <listitem>
      <para>Valgrind translates and instruments your program's machine
      code in small fragments (basic blocks). The translations are stored in a
      translation cache that is divided into a number of sections
      (sectors). If the cache is full, the sector containing the
      oldest translations is emptied and reused. If these old
      translations are needed again, Valgrind must re-translate and
      re-instrument the corresponding machine code, which is
      expensive.  If the "executed instructions" working set of a
      program is big, increasing the number of sectors may improve
      performance by reducing the number of re-translations needed.
      Sectors are allocated on demand.  Once allocated, a sector can
      never be freed, and occupies considerable space, depending on the tool
      and the value of <option>--avg-transtab-entry-size</option>
      (about 40 MB per sector for Memcheck).  Use the
      option <option>--stats=yes</option> to obtain precise
      information about the memory used by a sector and the allocation
      and recycling of sectors.</para>
   </listitem>
  </varlistentry>

  <varlistentry id="opt.avg-transtab-entry-size" xreflabel="--avg-transtab-entry-size">
    <term>
      <option><![CDATA[--avg-transtab-entry-size=<number> [default: 0,
      meaning use tool provided default] ]]></option>
    </term>
    <listitem>
      <para>Average size of translated basic block. This average size
      is used to dimension the size of a sector.
      Each tool provides a default value to be used.
      If this default value is too small, the translation sectors
      will become full too quickly. If this default value is too big,
      a significant part of the translation sector memory will be unused.
      Note that the average size of a basic block translation depends
      on the tool, and might depend on tool options. For example,
      the memcheck option <option>--track-origins=yes</option>
      increases the size of the basic block translations.
      Use <option>--avg-transtab-entry-size</option> to tune the size of the
      sectors, either to gain memory or to avoid too many retranslations.
      </para>
   </listitem>
  </varlistentry>

  <varlistentry id="opt.aspace-minaddr" xreflabel="----aspace-minaddr">
    <term>
      <option><![CDATA[--aspace-minaddr=<address> [default: depends
      on the platform] ]]></option>
    </term>
    <listitem>
      <para>To avoid potential conflicts with some system libraries,
      Valgrind does not use the address space
      below <option>--aspace-minaddr</option> value, keeping it
      reserved in case a library specifically requests memory in this
      region.  So, some "pessimistic" value is guessed by Valgrind
      depending on the platform. On linux, by default, Valgrind avoids
      using the first 64MB even if typically there is no conflict in
      this complete zone.  You can use the
      option <option>--aspace-minaddr</option> to have your memory
      hungry application benefitting from more of this lower memory.
      On the other hand, if you encounter a conflict, increasing
      aspace-minaddr value might solve it. Conflicts will typically
      manifest themselves with mmap failures in the low range of the
      address space. The
      provided <computeroutput>address</computeroutput> must be page
      aligned and must be equal or bigger to 0x1000 (4KB). To find the
      default value on your platform, do something such as
      <computeroutput>valgrind -d -d date 2&gt;&amp;1 | grep -i minaddr</computeroutput>.
      Values lower than 0x10000 (64KB) are known to create problems
      on some distributions.
      </para>
   </listitem>
  </varlistentry>

  <varlistentry id="opt.valgrind-stacksize" xreflabel="----valgrind-stacksize">
    <term>
      <option><![CDATA[--valgrind-stacksize=<number> [default: 1MB] ]]></option>
    </term>
    <listitem>
      <para>For each thread, Valgrind needs its own 'private' stack.
      The default size for these stacks is largely dimensioned, and so
      should be sufficient in most cases.  In case the size is too small,
      Valgrind will segfault. Before segfaulting, a warning might be produced
      by Valgrind when approaching the limit.
      </para>
      <para>
      Use the option <option>--valgrind-stacksize</option> if such an (unlikely)
      warning is produced, or Valgrind dies due to a segmentation violation.
      Such segmentation violations have been seen when demangling huge C++
      symbols.
      </para>
      <para>If your application uses many threads and needs a lot of memory, you can
      gain some memory by reducing the size of these Valgrind stacks using
      the option <option>--valgrind-stacksize</option>.
      </para>
   </listitem>
  </varlistentry>

  <varlistentry id="opt.show-emwarns" xreflabel="--show-emwarns">
    <term>
      <option><![CDATA[--show-emwarns=<yes|no> [default: no] ]]></option>
    </term>
    <listitem>
      <para>When enabled, Valgrind will emit warnings about its CPU
      emulation in certain cases.  These are usually not
      interesting.</para>
   </listitem>
  </varlistentry>

  <varlistentry id="opt.require-text-symbol"
        xreflabel="--require-text-symbol">
    <term>
      <option><![CDATA[--require-text-symbol=:sonamepatt:fnnamepatt]]></option>
    </term>
    <listitem>
      <para>When a shared object whose soname
      matches <varname>sonamepatt</varname> is loaded into the
      process, examine all the text symbols it exports.  If none of
      those match <varname>fnnamepatt</varname>, print an error
      message and abandon the run.  This makes it possible to ensure
      that the run does not continue unless a given shared object
      contains a particular function name.
      </para>
      <para>
      Both <varname>sonamepatt</varname> and
      <varname>fnnamepatt</varname> can be written using the usual
      <varname>?</varname> and <varname>*</varname> wildcards.  For
      example: <varname>":*libc.so*:foo?bar"</varname>.  You may use
      characters other than a colon to separate the two patterns.  It
      is only important that the first character and the separator
      character are the same.  For example, the above example could
      also be written <varname>"Q*libc.so*Qfoo?bar"</varname>.
      Multiple <varname> --require-text-symbol</varname> flags are
      allowed, in which case shared objects that are loaded into
      the process will be checked against all of them.
      </para>
      <para>
      The purpose of this is to support reliable usage of marked-up
      libraries.  For example, suppose we have a version of GCC's
      <varname>libgomp.so</varname> which has been marked up with
      annotations to support Helgrind.  It is only too easy and
      confusing to load the wrong, un-annotated
      <varname>libgomp.so</varname> into the application.  So the idea
      is: add a text symbol in the marked-up library, for
      example <varname>annotated_for_helgrind_3_6</varname>, and then
      give the flag
      <varname>--require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6</varname>
      so that when <varname>libgomp.so</varname> is loaded, Valgrind
      scans its symbol table, and if the symbol isn't present the run
      is aborted, rather than continuing silently with the
      un-marked-up library.  Note that you should put the entire flag
      in quotes to stop shells expanding up the <varname>*</varname>
      and <varname>?</varname> wildcards.
      </para>
   </listitem>
  </varlistentry>

  <varlistentry id="opt.soname-synonyms"
        xreflabel="--soname-synonyms">
    <term>
      <option><![CDATA[--soname-synonyms=syn1=pattern1,syn2=pattern2,...]]></option>
    </term>
    <listitem>
      <para>When a shared library is loaded, Valgrind checks for
      functions in the library that must be replaced or wrapped.  For
      example, Memcheck replaces some string and memory functions
      (strchr, strlen, strcpy, memchr, memcpy, memmove, etc.) with its
      own versions.  Such replacements are normally done only in shared
      libraries whose soname matches a predefined soname pattern (e.g.
      <varname>libc.so*</varname> on linux).  By default, no
      replacement is done for a statically linked binary or for
      alternative libraries, except for the allocation functions
      (malloc, free, calloc, memalign, realloc, operator new, operator
      delete, etc.) Such allocation functions are intercepted by
      default in any shared library or in the executable if they are
      exported as global symbols. This means that if a replacement
      allocation library such as tcmalloc is found, its functions are
      also intercepted by default.

      In some cases, the replacements allow
      <option>--soname-synonyms</option> to specify one additional
      synonym pattern, giving flexibility in the replacement.  Or to
      prevent interception of all public allocation symbols.</para>

      <para>Currently, this flexibility is only allowed for the
      malloc related functions, using the
      synonym <varname>somalloc</varname>.  This synonym is usable for
      all tools doing standard replacement of malloc related functions
      (e.g. memcheck, massif, drd, helgrind, exp-dhat, exp-sgcheck).
      </para>

      <itemizedlist>
        <listitem>

          <para>Alternate malloc library: to replace the malloc
          related functions in a specific alternate library with
          soname <varname>mymalloclib.so</varname> (and not in any
          others), give the
          option <option>--soname-synonyms=somalloc=mymalloclib.so</option>.
          A pattern can be used to match multiple libraries sonames.
          For
          example, <option>--soname-synonyms=somalloc=*tcmalloc*</option>
          will match the soname of all variants of the tcmalloc
          library (native, debug, profiled, ... tcmalloc
          variants). </para>
          <para>Note: the soname of a elf shared library can be
          retrieved using the readelf utility. </para>

        </listitem>

        <listitem>
          <para>Replacements in a statically linked library are done
          by using the <varname>NONE</varname> pattern. For example,
          if you link with <varname>libtcmalloc.a</varname>, and only
          want to intercept the malloc related functions in the
          executable (and standard libraries) themselves, but not any
          other shared libraries, you can give the
          option <option>--soname-synonyms=somalloc=NONE</option>.
          Note that a NONE pattern will match the main executable and
          any shared library having no soname. </para>
        </listitem>

        <listitem>
          <para>To run a "default" Firefox build for Linux, in which
          JEMalloc is linked in to the main executable,
          use <option>--soname-synonyms=somalloc=NONE</option>.
          </para>
        </listitem>

	<listitem>
	  <para>To only intercept allocation symbols in the default
	  system libraries, but not in any other shared library or the
	  executable defining public malloc or operator new related
	  functions use a non-existing library name
	  like <option>--soname-synonyms=somalloc=nouserintercepts</option>
	  (where <varname>nouserintercepts</varname> can be any
	  non-existing library name).
	  </para>
	</listitem>

      <listitem>
         <para>Shared library of the dynamic (runtime) linker is excluded from
         searching for global public symbols, such as those for the malloc
         related functions (identified by <varname>somalloc</varname> synonym).
         </para>
      </listitem>

      </itemizedlist>
   </listitem>
  </varlistentry>


</variablelist>
<!-- end of xi:include in the manpage -->

</sect2>


<sect2 id="manual-core.debugopts" xreflabel="Debugging Options">
<title>Debugging Options</title>

<!-- start of xi:include in the manpage -->
<para id="debug.opts.para">There are also some options for debugging
Valgrind itself.  You shouldn't need to use them in the normal run of
things.  If you wish to see the list, use the
<option>--help-debug</option> option.</para>

<para>If you wish to debug your program rather than debugging
Valgrind itself, then you should use the options
<option>--vgdb=yes</option> or <option>--vgdb=full</option>.
</para>

<!-- end of xi:include in the manpage -->

</sect2>


<sect2 id="manual-core.defopts" xreflabel="Setting Default Options">
<title>Setting Default Options</title>

<para>Note that Valgrind also reads options from three places:</para>

  <orderedlist>
   <listitem>
    <para>The file <computeroutput>~/.valgrindrc</computeroutput></para>
   </listitem>

   <listitem>
    <para>The environment variable
    <computeroutput>$VALGRIND_OPTS</computeroutput></para>
   </listitem>

   <listitem>
    <para>The file <computeroutput>./.valgrindrc</computeroutput></para>
   </listitem>
  </orderedlist>

<para>These are processed in the given order, before the
command-line options.  Options processed later override those
processed earlier; for example, options in
<computeroutput>./.valgrindrc</computeroutput> will take
precedence over those in
<computeroutput>~/.valgrindrc</computeroutput>.
</para>

<para>Please note that the <computeroutput>./.valgrindrc</computeroutput>
file is ignored if it is marked as world writeable or not owned 
by the current user. This is because the
<computeroutput>./.valgrindrc</computeroutput> can contain options that are
potentially harmful or can be used by a local attacker to execute code under
your user account.
</para>

<para>Any tool-specific options put in
<computeroutput>$VALGRIND_OPTS</computeroutput> or the
<computeroutput>.valgrindrc</computeroutput> files should be
prefixed with the tool name and a colon.  For example, if you
want Memcheck to always do leak checking, you can put the
following entry in <literal>~/.valgrindrc</literal>:</para>

<programlisting><![CDATA[
--memcheck:leak-check=yes]]></programlisting>

<para>This will be ignored if any tool other than Memcheck is
run.  Without the <computeroutput>memcheck:</computeroutput>
part, this will cause problems if you select other tools that
don't understand
<option>--leak-check=yes</option>.</para>

</sect2>

</sect1>



<sect1 id="manual-core.pthreads" xreflabel="Support for Threads">
<title>Support for Threads</title>

<para>Threaded programs are fully supported.</para>

<para>The main thing to point out with respect to threaded programs is
that your program will use the native threading library, but Valgrind
serialises execution so that only one (kernel) thread is running at a
time.  This approach avoids the horrible implementation problems of
implementing a truly multithreaded version of Valgrind, but it does
mean that threaded apps never use more than one CPU simultaneously,
even if you have a multiprocessor or multicore machine.</para>

<para>Valgrind doesn't schedule the threads itself.  It merely ensures
that only one thread runs at once, using a simple locking scheme.  The
actual thread scheduling remains under control of the OS kernel.  What
this does mean, though, is that your program will see very different
scheduling when run on Valgrind than it does when running normally.
This is both because Valgrind is serialising the threads, and because
the code runs so much slower than normal.</para>

<para>This difference in scheduling may cause your program to behave
differently, if you have some kind of concurrency, critical race,
locking, or similar, bugs.  In that case you might consider using the
tools Helgrind and/or DRD to track them down.</para>

<para>On Linux, Valgrind also supports direct use of the
<computeroutput>clone</computeroutput> system call,
<computeroutput>futex</computeroutput> and so on.
<computeroutput>clone</computeroutput> is supported where either
everything is shared (a thread) or nothing is shared (fork-like); partial
sharing will fail.
</para>

<!-- Referenced from both the manual and manpage -->
<sect2 id="&vg-pthreads-perf-sched-id;" xreflabel="&vg-pthreads-perf-sched-label;">
<title>Scheduling and Multi-Thread Performance</title>

<para>A thread executes code only when it holds the abovementioned
lock.  After executing some number of instructions, the running thread
will release the lock.  All threads ready to run will then compete to
acquire the lock.</para>

<para>The <option>--fair-sched</option> option controls the locking mechanism
used to serialise thread execution.</para>

<para>The default pipe based locking mechanism
(<option>--fair-sched=no</option>) is available on all
platforms.  Pipe based locking does not guarantee fairness between
threads: it is quite likely that a thread that has just released the
lock reacquires it immediately, even though other threads are ready to
run.  When using pipe based locking, different runs of the same
multithreaded application might give very different thread
scheduling.</para>

<para>An alternative locking mechanism, based on futexes, is available
on some platforms.  If available, it is activated
by <option>--fair-sched=yes</option> or
<option>--fair-sched=try</option>.  Futex based locking ensures
fairness (round-robin scheduling) between threads: if multiple threads
are ready to run, the lock will be given to the thread which first
requested the lock.  Note that a thread which is blocked in a system
call (e.g. in a blocking read system call) has not (yet) requested the
lock: such a thread requests the lock only after the system call is
finished.</para>

<para> The fairness of the futex based locking produces better
reproducibility of thread scheduling for different executions of a
multithreaded application. This better reproducibility is particularly
helpful when using Helgrind or DRD.</para>

<para>Valgrind's use of thread serialisation implies that only one
thread at a time may run.  On a multiprocessor/multicore system, the
running thread is assigned to one of the CPUs by the OS kernel
scheduler.  When a thread acquires the lock, sometimes the thread will
be assigned to the same CPU as the thread that just released the
lock.  Sometimes, the thread will be assigned to another CPU.  When
using pipe based locking, the thread that just acquired the lock
will usually be scheduled on the same CPU as the thread that just
released the lock.  With the futex based mechanism, the thread that
just acquired the lock will more often be scheduled on another
CPU.</para>

<para>Valgrind's thread serialisation and CPU assignment by the OS
kernel scheduler can interact badly with the CPU frequency scaling
available on many modern CPUs.  To decrease power consumption, the
frequency of a CPU or core is automatically decreased if the CPU/core
has not been used recently.  If the OS kernel often assigns the thread
which just acquired the lock to another CPU/core, it is quite likely
that this CPU/core is currently at a low frequency.  The frequency of
this CPU will be increased after some time.  However, during this
time, the (only) running thread will have run at the low frequency.
Once this thread has run for some time, it will release the lock.
Another thread will acquire this lock, and might be scheduled again on
another CPU whose clock frequency was decreased in the
meantime.</para>

<para>The futex based locking causes threads to change CPUs/cores more
often.  So, if CPU frequency scaling is activated, the futex based
locking might decrease significantly the performance of a
multithreaded app running under Valgrind.  Performance losses of up to
50% degradation have been observed, as compared to running on a
machine for which CPU frequency scaling has been disabled.  The pipe
based locking locking scheme also interacts badly with CPU frequency
scaling, with performance losses in the range 10..20% having been
observed.</para>

<para>To avoid such performance degradation, you should indicate to
the kernel that all CPUs/cores should always run at maximum clock
speed.  Depending on your Linux distribution, CPU frequency scaling
may be controlled using a graphical interface or using command line
such as
<computeroutput>cpufreq-selector</computeroutput> or
<computeroutput>cpufreq-set</computeroutput>.
</para>

<para>An alternative way to avoid these problems is to tell the
OS scheduler to tie a Valgrind process to a specific (fixed) CPU using the
<computeroutput>taskset</computeroutput> command.  This should ensure
that the selected CPU does not fall below its maximum frequency
setting so long as any thread of the program has work to do.
</para>

</sect2>


</sect1>

<sect1 id="manual-core.signals" xreflabel="Handling of Signals">
<title>Handling of Signals</title>

<para>Valgrind has a fairly complete signal implementation.  It should be
able to cope with any POSIX-compliant use of signals.</para>
 
<para>If you're using signals in clever ways (for example, catching
SIGSEGV, modifying page state and restarting the instruction), you're
probably relying on precise exceptions.  In this case, you will need
to use <option>--vex-iropt-register-updates=allregs-at-mem-access</option>
or <option>--vex-iropt-register-updates=allregs-at-each-insn</option>.
</para>

<para>If your program dies as a result of a fatal core-dumping signal,
Valgrind will generate its own core file
(<computeroutput>vgcore.NNNNN</computeroutput>) containing your program's
state.  You may use this core file for post-mortem debugging with GDB or
similar.  (Note: it will not generate a core if your core dump size limit is
0.)  At the time of writing the core dumps do not include all the floating
point register information.</para>

<para>In the unlikely event that Valgrind itself crashes, the operating system
will create a core dump in the usual way.</para>

</sect1>








<sect1 id="manual-core.install" xreflabel="Building and Installing">
<title>Building and Installing Valgrind</title>

<para>We use the standard Unix
<computeroutput>./configure</computeroutput>,
<computeroutput>make</computeroutput>, <computeroutput>make
install</computeroutput> mechanism.  Once you have completed 
<computeroutput>make install</computeroutput> you may then want 
to run the regression tests
with <computeroutput>make regtest</computeroutput>.
</para>

<para>In addition to the usual
<option>--prefix=/path/to/install/tree</option>, there are three
 options which affect how Valgrind is built:
<itemizedlist>

  <listitem>
    <para><option>--enable-inner</option></para>
    <para>This builds Valgrind with some special magic hacks which make
     it possible to run it on a standard build of Valgrind (what the
     developers call "self-hosting").  Ordinarily you should not use
     this option as various kinds of safety checks are disabled.
   </para>
  </listitem>

  <listitem>
    <para><option>--enable-only64bit</option></para>
    <para><option>--enable-only32bit</option></para>
    <para>On 64-bit platforms (amd64-linux, ppc64-linux,
     amd64-darwin), Valgrind is by default built in such a way that
     both 32-bit and 64-bit executables can be run.  Sometimes this
     cleverness is a problem for a variety of reasons.  These two
     options allow for single-target builds in this situation.  If you
     issue both, the configure script will complain.  Note they are
     ignored on 32-bit-only platforms (x86-linux, ppc32-linux,
     arm-linux, x86-darwin).
   </para>
  </listitem>

</itemizedlist>
</para>

<para>The <computeroutput>configure</computeroutput> script tests
the version of the X server currently indicated by the current
<computeroutput>$DISPLAY</computeroutput>.  This is a known bug.
The intention was to detect the version of the current X
client libraries, so that correct suppressions could be selected
for them, but instead the test checks the server version.  This
is just plain wrong.</para>

<para>If you are building a binary package of Valgrind for
distribution, please read <literal>README_PACKAGERS</literal>
<xref linkend="dist.readme-packagers"/>.  It contains some
important information.</para>

<para>Apart from that, there's not much excitement here.  Let us
know if you have build problems.</para>

</sect1>



<sect1 id="manual-core.problems" xreflabel="If You Have Problems">
<title>If You Have Problems</title>

<para>Contact us at <ulink url="&vg-url;">&vg-url;</ulink>.</para>

<para>See <xref linkend="manual-core.limits"/> for the known
limitations of Valgrind, and for a list of programs which are
known not to work on it.</para>

<para>All parts of the system make heavy use of assertions and 
internal self-checks.  They are permanently enabled, and we have no 
plans to disable them.  If one of them breaks, please mail us!</para>

<para>If you get an assertion failure
in <filename>m_mallocfree.c</filename>, this may have happened because
your program wrote off the end of a heap block, or before its
beginning, thus corrupting heap metadata.  Valgrind hopefully will have
emitted a message to that effect before dying in this way.</para>

<para>Read the <xref linkend="FAQ"/> for more advice about common problems, 
crashes, etc.</para>

</sect1>



<sect1 id="manual-core.limits" xreflabel="Limitations">
<title>Limitations</title>

<para>The following list of limitations seems long.  However, most
programs actually work fine.</para>

<para>Valgrind will run programs on the supported platforms
subject to the following constraints:</para>

 <itemizedlist>
  <listitem>
    <para>On Linux, Valgrind determines at startup the size of the 'brk
      segment' using the RLIMIT_DATA rlim_cur, with a minimum of 1 MB and
      a maximum of 8 MB. Valgrind outputs a message each time a program
      tries to extend the brk segment beyond the size determined at
      startup.  Most programs will work properly with this limit,
      typically by switching to the use of mmap to get more memory.
      If your program really needs a big brk segment, you must change
      the 8 MB hardcoded limit and recompile Valgrind.
   </para>
  </listitem>

  <listitem>
   <para>On x86 and amd64, there is no support for 3DNow!
   instructions.  If the translator encounters these, Valgrind will
   generate a SIGILL when the instruction is executed.  Apart from
   that, on x86 and amd64, essentially all instructions are supported,
   up to and including AVX and AES in 64-bit mode and SSSE3 in 32-bit
   mode.  32-bit mode does in fact support the bare minimum SSE4
   instructions needed to run programs on MacOSX 10.6 on 32-bit
   targets.
   </para>
  </listitem>

  <listitem>
   <para>On ppc32 and ppc64, almost all integer, floating point and
   Altivec instructions are supported.  Specifically: integer and FP
   insns that are mandatory for PowerPC, the "General-purpose
   optional" group (fsqrt, fsqrts, stfiwx), the "Graphics optional"
   group (fre, fres, frsqrte, frsqrtes), and the Altivec (also known
   as VMX) SIMD instruction set, are supported.  Also, instructions
   from the Power ISA 2.05 specification, as present in POWER6 CPUs,
   are supported.</para>
  </listitem>

  <listitem>
   <para>On ARM, essentially the entire ARMv7-A instruction set
    is supported, in both ARM and Thumb mode.  ThumbEE and Jazelle are
    not supported.  NEON, VFPv3 and ARMv6 media support is fairly
    complete.
   </para>
  </listitem>

  <listitem>
   <para>If your program does its own memory management, rather than
   using malloc/new/free/delete, it should still work, but Memcheck's
   error checking won't be so effective.  If you describe your
   program's memory management scheme using "client requests" (see
   <xref linkend="manual-core-adv.clientreq"/>), Memcheck can do
   better.  Nevertheless, using malloc/new and free/delete is still
   the best approach.</para>
  </listitem>

  <listitem>
   <para>Valgrind's signal simulation is not as robust as it could be.
   Basic POSIX-compliant sigaction and sigprocmask functionality is
   supplied, but it's conceivable that things could go badly awry if you
   do weird things with signals.  Workaround: don't.  Programs that do
   non-POSIX signal tricks are in any case inherently unportable, so
   should be avoided if possible.</para>
  </listitem>

  <listitem>
   <para>Machine instructions, and system calls, have been implemented
   on demand.  So it's possible, although unlikely, that a program will
   fall over with a message to that effect.  If this happens, please
   report all the details printed out, so we can try and implement the
   missing feature.</para>
  </listitem>

  <listitem>
   <para>Memory consumption of your program is majorly increased
   whilst running under Valgrind's Memcheck tool.  This is due to the
   large amount of administrative information maintained behind the
   scenes.  Another cause is that Valgrind dynamically translates the
   original executable.  Translated, instrumented code is 12-18 times
   larger than the original so you can easily end up with 150+ MB of
   translations when running (eg) a web browser.</para>
  </listitem>

  <listitem>
   <para>Valgrind can handle dynamically-generated code just fine.  If
   you regenerate code over the top of old code (ie. at the same
   memory addresses), if the code is on the stack Valgrind will
   realise the code has changed, and work correctly.  This is
   necessary to handle the trampolines GCC uses to implemented nested
   functions.  If you regenerate code somewhere other than the stack,
   and you are running on an 32- or 64-bit x86 CPU, you will need to
   use the <option>--smc-check=all</option> option, and Valgrind will
   run more slowly than normal.  Or you can add client requests that
   tell Valgrind when your program has overwritten code.
   </para>
   <para> On other platforms (ARM, PowerPC) Valgrind observes and
   honours the cache invalidation hints that programs are obliged to
   emit to notify new code, and so self-modifying-code support should
   work automatically, without the need
   for <option>--smc-check=all</option>.</para>
  </listitem>

  <listitem>
   <para>Valgrind has the following limitations
   in its implementation of x86/AMD64 floating point relative to 
   IEEE754.</para>

   <para>Precision: There is no support for 80 bit arithmetic.
   Internally, Valgrind represents all such "long double" numbers in 64
   bits, and so there may be some differences in results.  Whether or
   not this is critical remains to be seen.  Note, the x86/amd64
   fldt/fstpt instructions (read/write 80-bit numbers) are correctly
   simulated, using conversions to/from 64 bits, so that in-memory
   images of 80-bit numbers look correct if anyone wants to see.</para>

   <para>The impression observed from many FP regression tests is that
   the accuracy differences aren't significant.  Generally speaking, if
   a program relies on 80-bit precision, there may be difficulties
   porting it to non x86/amd64 platforms which only support 64-bit FP
   precision.  Even on x86/amd64, the program may get different results
   depending on whether it is compiled to use SSE2 instructions (64-bits
   only), or x87 instructions (80-bit).  The net effect is to make FP
   programs behave as if they had been run on a machine with 64-bit IEEE
   floats, for example PowerPC.  On amd64 FP arithmetic is done by
   default on SSE2, so amd64 looks more like PowerPC than x86 from an FP
   perspective, and there are far fewer noticeable accuracy differences
   than with x86.</para>

   <para>Rounding: Valgrind does observe the 4 IEEE-mandated rounding
   modes (to nearest, to +infinity, to -infinity, to zero) for the
   following conversions: float to integer, integer to float where
   there is a possibility of loss of precision, and float-to-float
   rounding.  For all other FP operations, only the IEEE default mode
   (round to nearest) is supported.</para>

   <para>Numeric exceptions in FP code: IEEE754 defines five types of
   numeric exception that can happen: invalid operation (sqrt of
   negative number, etc), division by zero, overflow, underflow,
   inexact (loss of precision).</para>

   <para>For each exception, two courses of action are defined by IEEE754:
   either (1) a user-defined exception handler may be called, or (2) a
   default action is defined, which "fixes things up" and allows the
   computation to proceed without throwing an exception.</para>

   <para>Currently Valgrind only supports the default fixup actions.
   Again, feedback on the importance of exception support would be
   appreciated.</para>

   <para>When Valgrind detects that the program is trying to exceed any
   of these limitations (setting exception handlers, rounding mode, or
   precision control), it can print a message giving a traceback of
   where this has happened, and continue execution.  This behaviour used
   to be the default, but the messages are annoying and so showing them
   is now disabled by default.  Use <option>--show-emwarns=yes</option> to see
   them.</para>

   <para>The above limitations define precisely the IEEE754 'default'
   behaviour: default fixup on all exceptions, round-to-nearest
   operations, and 64-bit precision.</para>
  </listitem>
   
  <listitem>
   <para>Valgrind has the following limitations in
   its implementation of x86/AMD64 SSE2 FP arithmetic, relative to 
   IEEE754.</para>

   <para>Essentially the same: no exceptions, and limited observance of
   rounding mode.  Also, SSE2 has control bits which make it treat
   denormalised numbers as zero (DAZ) and a related action, flush
   denormals to zero (FTZ).  Both of these cause SSE2 arithmetic to be
   less accurate than IEEE requires.  Valgrind detects, ignores, and can
   warn about, attempts to enable either mode.</para>
  </listitem>

  <listitem>
   <para>Valgrind has the following limitations in
   its implementation of ARM VFPv3 arithmetic, relative to 
   IEEE754.</para>

   <para>Essentially the same: no exceptions, and limited observance
   of rounding mode.  Also, switching the VFP unit into vector mode
   will cause Valgrind to abort the program -- it has no way to
   emulate vector uses of VFP at a reasonable performance level.  This
   is no big deal given that non-scalar uses of VFP instructions are
   in any case deprecated.</para>
  </listitem>

  <listitem>
   <para>Valgrind has the following limitations
   in its implementation of PPC32 and PPC64 floating point 
   arithmetic, relative to IEEE754.</para>

   <para>Scalar (non-Altivec): Valgrind provides a bit-exact emulation of
   all floating point instructions, except for "fre" and "fres", which are
   done more precisely than required by the PowerPC architecture specification.
   All floating point operations observe the current rounding mode.
   </para>

   <para>However, fpscr[FPRF] is not set after each operation.  That could
   be done but would give measurable performance overheads, and so far
   no need for it has been found.</para>

   <para>As on x86/AMD64, IEEE754 exceptions are not supported: all floating
   point exceptions are handled using the default IEEE fixup actions.
   Valgrind detects, ignores, and can warn about, attempts to unmask 
   the 5 IEEE FP exception kinds by writing to the floating-point status 
   and control register (fpscr).
   </para>

   <para>Vector (Altivec, VMX): essentially as with x86/AMD64 SSE/SSE2: 
   no exceptions, and limited observance of rounding mode.  
   For Altivec, FP arithmetic
   is done in IEEE/Java mode, which is more accurate than the Linux default
   setting.  "More accurate" means that denormals are handled properly, 
   rather than simply being flushed to zero.</para>
  </listitem>
 </itemizedlist>

 <para>Programs which are known not to work are:</para>
 <itemizedlist>
  <listitem>
   <para>emacs starts up but immediately concludes it is out of
   memory and aborts.  It may be that Memcheck does not provide
   a good enough emulation of the 
   <computeroutput>mallinfo</computeroutput> function.
   Emacs works fine if you build it to use
   the standard malloc/free routines.</para>
  </listitem>
 </itemizedlist>

</sect1>


<sect1 id="manual-core.example" xreflabel="An Example Run">
<title>An Example Run</title>

<para>This is the log for a run of a small program using Memcheck.
The program is in fact correct, and the reported error is as the
result of a potentially serious code generation bug in GNU g++
(snapshot 20010527).</para>

<programlisting><![CDATA[
sewardj@phoenix:~/newmat10$ ~/Valgrind-6/valgrind -v ./bogon 
==25832== Valgrind 0.10, a memory error detector for x86 RedHat 7.1.
==25832== Copyright (C) 2000-2001, and GNU GPL'd, by Julian Seward.
==25832== Startup, with flags:
==25832== --suppressions=/home/sewardj/Valgrind/redhat71.supp
==25832== reading syms from /lib/ld-linux.so.2
==25832== reading syms from /lib/libc.so.6
==25832== reading syms from /mnt/pima/jrs/Inst/lib/libgcc_s.so.0
==25832== reading syms from /lib/libm.so.6
==25832== reading syms from /mnt/pima/jrs/Inst/lib/libstdc++.so.3
==25832== reading syms from /home/sewardj/Valgrind/valgrind.so
==25832== reading syms from /proc/self/exe
==25832== 
==25832== Invalid read of size 4
==25832==    at 0x8048724: BandMatrix::ReSize(int,int,int) (bogon.cpp:45)
==25832==    by 0x80487AF: main (bogon.cpp:66)
==25832==  Address 0xBFFFF74C is not stack'd, malloc'd or free'd
==25832==
==25832== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==25832== malloc/free: in use at exit: 0 bytes in 0 blocks.
==25832== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==25832== For a detailed leak analysis, rerun with: --leak-check=yes
]]></programlisting>

<para>The GCC folks fixed this about a week before GCC 3.0
shipped.</para>

</sect1>


<sect1 id="manual-core.warnings" xreflabel="Warning Messages">
<title>Warning Messages You Might See</title>

<para>Some of these only appear if you run in verbose mode
(enabled by <option>-v</option>):</para>

 <itemizedlist>

  <listitem>
    <para><computeroutput>More than 100 errors detected.  Subsequent
    errors will still be recorded, but in less detail than
    before.</computeroutput></para>

    <para>After 100 different errors have been shown, Valgrind becomes
    more conservative about collecting them.  It then requires only the
    program counters in the top two stack frames to match when deciding
    whether or not two errors are really the same one.  Prior to this
    point, the PCs in the top four frames are required to match.  This
    hack has the effect of slowing down the appearance of new errors
    after the first 100.  The 100 constant can be changed by recompiling
    Valgrind.</para>
  </listitem>

  <listitem>
    <para><computeroutput>More than 1000 errors detected.  I'm not
    reporting any more.  Final error counts may be inaccurate.  Go fix
    your program!</computeroutput></para>

    <para>After 1000 different errors have been detected, Valgrind
    ignores any more.  It seems unlikely that collecting even more
    different ones would be of practical help to anybody, and it avoids
    the danger that Valgrind spends more and more of its time comparing
    new errors against an ever-growing collection.  As above, the 1000
    number is a compile-time constant.</para>
  </listitem>

  <listitem>
    <para><computeroutput>Warning: client switching stacks?</computeroutput></para>

    <para>Valgrind spotted such a large change in the stack pointer
    that it guesses the client is switching to a different stack.  At
    this point it makes a kludgey guess where the base of the new
    stack is, and sets memory permissions accordingly.  At the moment
    "large change" is defined as a change of more that 2000000 in the
    value of the stack pointer register.  If Valgrind guesses wrong,
    you may get many bogus error messages following this and/or have
    crashes in the stack trace recording code.  You might avoid these
    problems by informing Valgrind about the stack bounds using
    VALGRIND_STACK_REGISTER client request. </para>

  </listitem>

  <listitem>
    <para><computeroutput>Warning: client attempted to close Valgrind's
    logfile fd &lt;number&gt;</computeroutput></para>

    <para>Valgrind doesn't allow the client to close the logfile,
    because you'd never see any diagnostic information after that point.
    If you see this message, you may want to use the
    <option>--log-fd=&lt;number&gt;</option> option to specify a
    different logfile file-descriptor number.</para>
  </listitem>

  <listitem>
    <para><computeroutput>Warning: noted but unhandled ioctl
    &lt;number&gt;</computeroutput></para>

    <para>Valgrind observed a call to one of the vast family of
    <computeroutput>ioctl</computeroutput> system calls, but did not
    modify its memory status info (because nobody has yet written a 
    suitable wrapper).  The call will still have gone through, but you may get
    spurious errors after this as a result of the non-update of the
    memory info.</para>
  </listitem>

  <listitem>
    <para><computeroutput>Warning: set address range perms: large range
    &lt;number></computeroutput></para>

    <para>Diagnostic message, mostly for benefit of the Valgrind
    developers, to do with memory permissions.</para>
  </listitem>

 </itemizedlist>

</sect1>






</chapter>