diff --git a/internals/memory-debugging.md b/internals/memory-debugging.md index 889fabad3..2c2fad19f 100644 --- a/internals/memory-debugging.md +++ b/internals/memory-debugging.md @@ -7,7 +7,7 @@ functions in the memdebug system do nothing fancy, they do their normal function and then log information about what they just did. The logged data can then be analyzed after a complete session, -`memanalyze.pl` is the perl script present in `tests/` that analyzes a log +`memanalyze.pl` is the Perl script present in `tests/` that analyzes a log file generated by the memory tracking system. It detects if resources are allocated but never freed and other kinds of errors related to resource management. @@ -30,13 +30,13 @@ restriction prevents memory tracking from being used. ## Track Down Memory Leaks -... using the memory debug system. In general, we suggest using valgrind a the +... using the memory debug system. In general, we suggest using valgrind as the first choice. ### Single-threaded Please note that this memory leak system is not adjusted to work in more than -one thread. If you want/need to use it in a multi-threaded app. Please adjust +one thread. If you want/need to use it in a multi-threaded app, please adjust accordingly. ### Build @@ -44,7 +44,7 @@ accordingly. Rebuild libcurl with `-DCURLDEBUG` (usually, rerunning configure with `--enable-debug` fixes this). `make clean` first, then `make` so that all files are actually rebuilt properly. It also makes sense to build libcurl with -the debug option (usually `-g` to the compiler) so that debugging it gets +the debug option (usually `-g` to the compiler) so that debugging gets easier if you actually do find a leak in the library. This builds a library that has memory debugging enabled. @@ -68,7 +68,7 @@ that all non-leaks are returned/freed properly. ### Analyze the Flow -Use the `tests/memanalyze.pl` perl script to analyze the dump file: +Use the `tests/memanalyze.pl` Perl script to analyze the dump file: $ tests/memanalyze.pl dump