From: Nicholas Nethercote Date: Wed, 5 Aug 2009 04:54:51 +0000 (+0000) Subject: Put Memcheck's command line options in the manual in the same order as its X-Git-Tag: svn/VALGRIND_3_5_0~138 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e06d3b4893d398418614b905464ef635e8cad4f3;p=thirdparty%2Fvalgrind.git Put Memcheck's command line options in the manual in the same order as its usage message. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10712 --- diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml index a1b8358cb0..afcdba6c42 100644 --- a/memcheck/docs/mc-manual.xml +++ b/memcheck/docs/mc-manual.xml @@ -64,6 +64,57 @@ difficult-to-diagnose crashes. + + + + + + When enabled, search for memory leaks when the client + program finishes. If set to summary, it says how + many leaks occurred. If set to full or + yes, it also gives details of each individual + leak. + + + + + + + + + When doing leak checking, determines how willing + Memcheck is to consider different backtraces to + be the same. When set to low, only the first + two entries need match. When med, four entries + have to match. When high, all entries need to + match; this is consistent with how merging occurs for other kinds of + errors. + + For hardcore leak debugging, you probably want to use + together with + or some such large number. + + + Note that the setting + does not affect Memcheck's ability to find + leaks. It only changes how the results are presented. + + + + + + + + + When disabled, the memory leak detector only shows "definitely + lost" and "possibly lost" blocks. When enabled, the leak detector also + shows "reachable" and "indirectly lost" blocks. (In other words, it + shows all blocks, except suppressed ones, so + would be a better name for + it.) + + + @@ -132,54 +183,28 @@ difficult-to-diagnose crashes. - - - - - - When enabled, search for memory leaks when the client - program finishes. If set to summary, it says how - many leaks occurred. If set to full or - yes, it also gives details of each individual - leak. - - - - - - - - - When disabled, the memory leak detector only shows "definitely - lost" and "possibly lost" blocks. When enabled, the leak detector also - shows "reachable" and "indirectly lost" blocks. (In other words, it - shows all blocks, except suppressed ones, so - would be a better name for - it.) - - - - + - + - When doing leak checking, determines how willing - Memcheck is to consider different backtraces to - be the same. When set to low, only the first - two entries need match. When med, four entries - have to match. When high, all entries need to - match; this is consistent with how merging occurs for other kinds of - errors. + Controls how Memcheck handles word-sized, + word-aligned loads from addresses for which some bytes are + addressable and others are not. When yes, such + loads do not produce an address error. Instead, loaded bytes + originating from illegal addresses are marked as uninitialised, and + those corresponding to legal addresses are handled in the normal + way. - For hardcore leak debugging, you probably want to use - together with - or some such large number. - + When no, loads from partially invalid + addresses are treated the same as loads from completely invalid + addresses: an illegal-address error is issued, and the resulting + bytes are marked as initialised. - Note that the setting - does not affect Memcheck's ability to find - leaks. It only changes how the results are presented. + Note that code that behaves in this way is in violation of + the the ISO C/C++ standards, and should be considered broken. If + at all possible, such code should be fixed. This flag should be + used only as a last resort. @@ -232,31 +257,6 @@ difficult-to-diagnose crashes. - - - - - - Controls how Memcheck handles word-sized, - word-aligned loads from addresses for which some bytes are - addressable and others are not. When yes, such - loads do not produce an address error. Instead, loaded bytes - originating from illegal addresses are marked as uninitialised, and - those corresponding to legal addresses are handled in the normal - way. - - When no, loads from partially invalid - addresses are treated the same as loads from completely invalid - addresses: an illegal-address error is issued, and the resulting - bytes are marked as initialised. - - Note that code that behaves in this way is in violation of - the the ISO C/C++ standards, and should be considered broken. If - at all possible, such code should be fixed. This flag should be - used only as a last resort. - - -