A few small cleanups in "Memory debugging"

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,21 +30,21 @@ 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
 
 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