Review five memory debuggers for Linux programming

Review five memory debuggers for Linux programming

2016-5-19 09:36 Comments: 1  Favorites: 5     

Credit: Moini

As a programmer, I know I'm bound to make mistakes - how can I not make mistakes! Programmers are human too. Some errors can be found in time during the coding process, while others have to wait until the software is tested to be revealed. However, there is another class of errors that cannot be resolved in these two stages, which causes the software to not run normally, or even terminate prematurely.

If you haven't guessed what kind of error it is, I'm talking about memory-related errors. Manually debugging these errors is time-consuming and difficult to spot and correct. It's worth mentioning that this kind of error is common, especially in software written in languages ​​like C/C++ that allow manual memory management .

Fortunately, there are now programming tools that can help you find these memory-related bugs in software programs. Among these toolsets, I evaluated five popular free and open source memory debuggers for Linux: Dmalloc, Electric Fence, Memcheck, Memwatch, and Mtrace. I already use all five debuggers in my day-to-day coding, so these evaluations are based on my actual experience.

Dmalloc

Developer : Gray Watson

Evaluation version : 5.5.2

Supported Linux Versions : All Kinds

License : CC 3.0

Dmalloc is a memory debugging tool developed by Gray Watson. It is implemented as a library that encapsulates standard memory management functions such as malloc(), calloc() , free()etc., allowing programmers to detect problematic code.

Dmalloc

Dmalloc

As shown on the tool's web page, features provided by this debugger include memory leak tracking,Repeatedly freeing memorydouble freebug tracking, andout of bounds writefence-post writedetection. Other features include reporting error file/line numbers, generic statistics logging.

Update details

Version 5.5.2 is a bugfix release that fixes several build and install issues.

What are the advantages

The biggest advantage of Dmalloc is its high configurability. For example, you can configure it to support C++ programs and multi-threaded applications. Dmalloc also provides a useful function: run-time configurable, which means that some features provided by Dmalloc can be easily enabled or disabled when it is executed.

You can also use Dmalloc with GNU Project Debugger (GDB) , just dmalloc.gdbadd the content of the file (located in the contrib subdirectory of the Dmalloc source package) to the file in your home directory .gdbinit.

Another advantage that makes me love Dmalloc is that it has a lot of information and literature. Go to the Documentation column of the official website , you can get all the details about how to download, install, run, how to use the library, and the features provided by Dmalloc, and the explanation of the output files it generates. There is also a chapter that presents solutions to common problems.

Precautions

Like Mtrace, Dmalloc requires programmers to modify their source code. For example, you can (and must) add header files dmalloc.h, and the tool will report the file or line number of the call that caused the problem. This feature is very useful because it saves debugging time.

In addition, you also need to link the Dmalloc library (generated when compiling the Dmalloc source code package) when compiling your program.

However, there is a bit more troublesome thing, you need to set an environment variable, named as DMALLOC_OPTION, for the tool to configure memory debugging features at runtime, such as defining the path of the output file. It is possible to manually assign a value to this environment variable, although beginners may find this process a bit difficult, because part of the value is used to indicate the Dmalloc feature to be enabled—expressed as an accumulated value of hexadecimal values. Here are the details.

A simpler way to set this environment variable is to use the Dmalloc utility directive , which is designed for this purpose.

Summarize

The real strength of Dmalloc is its configurable options. And highly portable, it has been successfully ported to various operating systems such as AIX, BSD/OS, DG/UX, Free/Net/OpenBSD, GNU/Hurd, HPUX, Irix, Linux, MS-DOG, NeXT, OSF, SCO, Solaris, SunOS, Ultrix, Unixware and even Unicos (running on a Cray T3E mainframe). While using Dmalloc requires a lot of learning, the features it provides are worth the price.

Electric Fence

Developer : Bruce Perens

Evaluation version : 2.2.3

Supported Linux Versions : All Kinds

License : GPL v2

Electric Fence is a memory debugging tool developed by Bruce Perens. It is implemented as a library, and your program needs to link it. Electric Fence can detect heap memory overflow and access to freed memory.

Electric Fence

Electric Fence

As the name implies, Electric Fence establishes a virtual fence at the boundary of each cache applied, so that any illegal memory access will cause a segmentation fault . This debugging tool supports both C and C++ programs.

Update details

Version 2.2.3 fixes the tool's build system so that -fno-builtin-mallocoptions can actually be passed to the GNU Compiler Collection (GCC) .

What are the advantages

The first thing I like about Electric Fence is that it is different from Memwatch, Dmalloc and Mtrace. You don't need to make any changes to your source code, you only need to link its library into your program at compile time.

Second, the Electric Fence implementation guarantees that the first instruction that produces an out-of-bounds access will cause a segmentation fault. This is much better than finding the problem later.

Electric Fence produces a copyright message in the output regardless of whether any errors are detected. This is very useful, so you can be sure that the program you are running has Electric Fence enabled.

Precautions

On the other hand, what I really miss about Electric Fence is its ability to detect memory leaks. Memory leaks are one of the most common and least-obvious problems in C/C++ software. However, Electric Fence cannot detect stack overflows and is not thread-safe.

Because Electric Fence will allocate prohibited virtual memory pages before and after the user allocates the memory area, if you perform too much dynamic memory allocation, your program will consume a lot of extra memory.

Another limitation of Electric Fence is that it cannot clearly indicate the line number of the error code. All it can do is segfault when it detects a memory-related error. If you want to locate the wrong line number, you need to use a debugging tool such as GDB to debug the program with Electric Fence enabled.

Finally, although Electric Fence can detect most buffer overflows, there is an exception that if the requested buffer size is not a multiple of the system word size, then the overflow (even if only a few bytes) cannot be detected come out.

Summarize

Despite its limitations, Electric Fence's ease of use is a plus. As long as the program is linked once, Electric Fence can report to the police when memory-related problems are detected. However, as mentioned earlier, Electric Fence needs to be used with a source code debugger like GDB.

Memcheck

Developer : Valgrind Development Team

Evaluation version : 3.10.1

Supported Linux Distributions : All Kinds

License : GPL

Valgrind is a suite that provides several tools for debugging and analyzing the performance of Linux programs. Although Valgrind can work with programs written in different languages—Java, Perl, Python, Assembly code, ortran, Ada, etc.—it is mainly aimed at programs written in C/C++.

Memcheck, a memory error detector, is the most popular of these tools. It detects issues such as memory leaks, invalid memory accesses, usage of undefined variables, and issues related to heap memory allocation and deallocation.

Update details

Toolkit (3.10.1) mainly fixes bugs found in version 3.10.0. Among other things, "some patches backported from the mainline development version, fixing missing AArch64 ARMv8 instructions and syscalls".

What are the advantages

Like all other Valgrind tools, Memcheck is a command-line program. Its operation is very simple: usually we use prog arg1 arg2commands such as the format to run the program, and Memcheck only requires you to add a few more values, such as valgrind --leak-check=full prog arg1 arg2.

Memcheck

Memcheck

-g(Note: Because Memcheck is the default tool of Valgrind, there is no need to mention Memcheck when executing commands on the command line. However, you need to bring parameter options at the beginning of the compilation program. This step will add debugging information, so that the error message of Memcheck will include correct line number.)

What I really like about Memcheck is that it provides a lot of command line options ( --leak-checkoptions mentioned above) so that you can control not only how the tool behaves but also its output.

For example, --track-originsthe option can be turned on to view uninitialized data in the program source code; --show-mismatched-freesthe option can be turned on to let Memcheck match memory allocation and deallocation techniques. For code written in C language, Memcheck will ensure that only free()functions can be used to release memory and malloc()functions to apply for memory. For the source code written in C++, Memcheck will check whether the deleteor delete[]operator is used to release memory, and newor new[]to apply for memory.

The best feature of Memcheck, especially for beginners, is that it advises the user which command-line options to use to make the output more meaningful. For example, if you don't use the basic --leak-checkoptions, Memcheck will suggest in the output: "Rerun with --leak-check=full to see more leaked memory details". If the program has uninitialized variables, Memcheck will produce the message: "use --track-origins=yes to see the origin of uninitialized variables".

Another useful feature of Memcheck is that it can createsuppress file suppression files , so that specific uncorrectable errors can be skipped, so that Memcheck won't warn every time it runs. It is worth mentioning that Memcheck will read the default suppression file to ignore errors in system libraries (such as C library), which exist before the system is created. You can choose to create a new suppression file, or edit an existing file (usually /usr/lib/valgrind/default.supp).

Memcheck also has advanced features, such as the ability to use a custom memory allocator to detect memory errors . In addition, Memcheck provides monitoring commands , which can be used when using Valgrind's built-in gdbserver and the client request mechanism (not only can inform Memcheck of the program's behavior, but also can query).

Precautions

There is no doubt that Memcheck can save a lot of debugging time and a lot of trouble. But it uses a lot of memory, causing program execution to slow down ( about 20 to 30 times longer, according to the documentation ).

In addition, Memcheck has other limitations. According to user comments, Memcheck is clearly not thread-safe ; it cannot detect static buffer overflows ; and, moreover, some Linux programs such as GNU Emacs do not currently work with Memcheck.

If interested, a detailed description of the limitations of Valgrind can be found here .

Summarize

Memcheck is a handy memory debugging tool for both beginners and those who need advanced features. If you just need basic debugging and error checking, Memcheck is very easy to get started. And when you want to use features like suppress files or watch commands, it takes some learning.

While listing numerous limitations, Valgrind (including Memcheck) claims on its website that the tool is used by thousands of programmers worldwide. The development team claims to have received feedback from users in more than 30 countries, and some of these users' engineering codes are as high as 25 million lines.

Memwatch

Developer : Johan Lindh

Evaluation version : 2.71

Supported Linux Distributions : All Kinds

License : GNU GPL

Memwatch is a memory debugging tool developed by Johan Lindh, although it plays the main role as a memory leak detector, but (according to the web page introduction) it also has the ability to detect other things such as memory double release and error release, buffer overflow and underflow , wild The ability to write pointers and other memory-related issues.

Memwatch supports programs written in C language. It is also possible to use it in C++ programs, but this practice is discouraged (as seen in the Q&A file accompanying the Memwatch source package).

Update details

This release adds ULONG_LONG_MAXto distinguish between 32-bit and 64-bit programs.

What are the advantages

Like Dmalloc, Memwatch has excellent documentation. Refer to the USING file, you can learn how to use Memwatch, you can understand how Memwatch is initialized, how to clean up, how to perform I/O operations, and so on. There is also an FAQ file designed to help users solve general problems encountered during use. There is also a test.cdocument at the end that provides working case references.

Memwatch

Memwatch

Unlike MTrace, the log files produced by Memwatch are (usually memwatch.log) in a human-readable format. Also, Memwatch will always splice the memory debug results to the end of the output file each time it is run. This makes it easy to review previous output information should the need arise.

It's also worth mentioning that when you execute a program that enables Memwatch, Memwatch will produce a single line on standard output saying that an error was found, and you can then view the output details in the log file. If no error messages are generated, you can ensure that no errors are written to the log file, and running it multiple times can really save time.

Another advantage I like is that Memwatch also provides a way to get its output information in the source code, you can get the information, and let it do what you want (see the function in the Memwatch source code for more information on this) mwSetOutFunc().

Precautions

Like Mtrace and Dmalloc, Memwatch also requires you to add code to your source files: you need to include memwatch.hthis header file in your code. Moreover, when compiling the program, you need to memwatch.ccompile together; or you can include the compiled object module, and then define MEMWATCHand MW_STDIOvariables on the command line. Needless to say, the -g compiler option is indispensable for locating line numbers in the output.

Also, Memwatch lacks some features. For example, Memwatch cannot detect a write operation to a block of memory that has been freed, or a read operation outside the allocated memory block. Also, Memwatch is not thread safe. Also, as I pointed out at the beginning, the results of running Memwatch on a C++ program are unpredictable.

Summarize

Memcheck can detect many memory-related problems and is a very handy debugging tool when dealing with C programs. Because the source code is small, you can understand how Memcheck works, debug it if necessary, and even expand and upgrade its functions according to your own needs.

Mtrace

Developers : Roland McGrath and Ulrich Drepper

Evaluation version : 2.21

Supported Linux Distributions : All Kinds

License : GNU GPL

Mtrace is a memory debugging tool in the GNU C library , which supports both C and C++ programs on Linux, and can detect memory leaks caused by functions malloc()and free()mismatched calls.

Mtrace

Mtrace

Mtrace actually implements a mtrace()function named mtrace, which can trace all malloc/free calls in the program and record relevant information in the file specified by the user. The files record data in a machine-readable format, so a Perl script -- also named mtrace -- is used to convert the files into a human-readable format.

Update details

The MTrace source code and Perl documentation are released together with the GNU C library (version 2.21), with no changes other than an updated copyright date.

What are the advantages

The best thing about MTrace is that it is very easy to learn. mtrace()You just need to know how and where to add and the corresponding functions in your source code muntrace(), and how to use MTrace's Perl script. The latter is very simple and only needs to run the command mtrace <program-executable> <log-file-generated-upon-program-execution>(see the last command in the screenshot at the beginning for an example).

Another advantage of MTrace is its scalability, which is reflected in the fact that it can be used not only to debug complete programs, but also to detect memory leaks in individual modules of a program. mtrace()Just call and in each module muntrace().

Last but not least, because MTrace is mtrace()triggered when - a function added in the source code - is executed, it is very flexible to use signals to enable MTrace dynamically (while the program is executing).

Precautions

Because mtrace()calls to mauntrace()functions—declared in mcheck.hfiles, so the header file must be included in the source code—are fundamental to the work of MTrace ( mauntrace()functions are not always necessary ), MTrace requires the programmer to change the source code at least once.

It should be noted that when compiling the program, bring the -g option (both GCC and G++ compilers provide it), so that the debugging tool can display the correct line number when outputting the result. Besides, some programs (depending on how big the source code is) may take a long time to compile. Finally, compiling with the -g option increases the size of the executable (because of the extra debug information provided), so remember that the program needs to be recompiled without the -g option after testing.

To use Mtrace, you need to master the basic knowledge of Linux environment variables, because before the program is executed, the user needs to set the MALLOC_TRACEvalue of the environment variable to the path of the specified file ( mtrace()the function will record all information into it).

Mtrace has limitations in detecting memory leaks and attempts to free unallocated memory. It cannot detect other memory related issues such as illegal memory access, use of uninitialized memory. Also, there are complaints that Mtrace is not thread-safe .

Summarize

It goes without saying that each of the memory debuggers I've discussed here has its strengths and limitations. So, which one is right for you depends on the features you need, although sometimes ease of installation and use is also a deciding factor.

Mtrace is perfect for catching memory leaks in software programs. It also saves time. Since the Linux system has pre-installed this tool, Mtrace is also very helpful for situations where the Internet cannot be connected or third-party debugging tools cannot be downloaded.

On the other hand, compared to Mtrace, Dmalloc not only can detect more error types, but also provides more features, such as runtime configuration and GDB integration. Also, Dmalloc, unlike the other tools mentioned here, is thread-safe. Not to mention its detailed profile, which makes Dmalloc ideal for beginners.

Although Memwatch has more information than Dmalloc and can detect more types of errors, you can only use it in programs written in C language. One feature that makes Memwatch stand out is that it allows you to handle its output in your program source code, which is very useful if you want to customize the output format.

If changing the program source code is not your wish, then use Electric Fence. However, keep in mind that Electric Fence can only detect two types of errors, neither of which are memory leaks. Also, a basic understanding of GDB is required to maximize the utility of this memory debugging tool.

Memcheck is probably the most comprehensive of the bunch. It detects more error types, provides more features than any other tool mentioned here, and doesn't require any changes to your source code. But please note that the basic functions are not difficult to use, but if you want to use its advanced features, you must learn relevant professional knowledge.


via: http://www.computerworld.com/article/3003957/linux/review-5-memory-debuggers-for-linux-coding.html

Credit: Moini

As a programmer, I know I'm bound to make mistakes - how can I not make mistakes! Programmers are human too. Some errors can be found in time during the coding process, while others have to wait until the software is tested to be revealed. However, there is another class of errors that cannot be resolved in these two stages, which causes the software to not run normally, or even terminate prematurely.

If you haven't guessed what kind of error it is, I'm talking about memory-related errors. Manually debugging these errors is time-consuming and difficult to spot and correct. It's worth mentioning that this kind of error is common, especially in software written in languages ​​like C/C++ that allow manual memory management .

Fortunately, there are now programming tools that can help you find these memory-related bugs in software programs. Among these toolsets, I evaluated five popular free and open source memory debuggers for Linux: Dmalloc, Electric Fence, Memcheck, Memwatch, and Mtrace. I already use all five debuggers in my day-to-day coding, so these evaluations are based on my actual experience.

Dmalloc

Developer : Gray Watson

Evaluation version : 5.5.2

Supported Linux Versions : All Kinds

License : CC 3.0

Dmalloc is a memory debugging tool developed by Gray Watson. It is implemented as a library that encapsulates standard memory management functions such as malloc(), calloc() , free()etc., allowing programmers to detect problematic code.

Dmalloc

Dmalloc

As shown on the tool's web page, features provided by this debugger include memory leak tracking,Repeatedly freeing memorydouble freebug tracking, andout of bounds writefence-post writedetection. Other features include reporting error file/line numbers, generic statistics logging.

Update details

Version 5.5.2 is a bugfix release that fixes several build and install issues.

What are the advantages

The biggest advantage of Dmalloc is its high configurability. For example, you can configure it to support C++ programs and multi-threaded applications. Dmalloc also provides a useful function: run-time configurable, which means that some features provided by Dmalloc can be easily enabled or disabled when it is executed.

You can also use Dmalloc with GNU Project Debugger (GDB) , just dmalloc.gdbadd the content of the file (located in the contrib subdirectory of the Dmalloc source package) to the file in your home directory .gdbinit.

Another advantage that makes me love Dmalloc is that it has a lot of information and literature. Go to the Documentation column of the official website , you can get all the details about how to download, install, run, how to use the library, and the features provided by Dmalloc, and the explanation of the output files it generates. There is also a chapter that presents solutions to common problems.

Precautions

Like Mtrace, Dmalloc requires programmers to modify their source code. For example, you can (and must) add header files dmalloc.h, and the tool will report the file or line number of the call that caused the problem. This feature is very useful because it saves debugging time.

In addition, you also need to link the Dmalloc library (generated when compiling the Dmalloc source code package) when compiling your program.

However, there is a bit more troublesome thing, you need to set an environment variable, named as DMALLOC_OPTION, for the tool to configure memory debugging features at runtime, such as defining the path of the output file. It is possible to manually assign a value to this environment variable, although beginners may find this process a bit difficult, because part of the value is used to indicate the Dmalloc feature to be enabled—expressed as an accumulated value of hexadecimal values. Here are the details.

A simpler way to set this environment variable is to use the Dmalloc utility directive , which is designed for this purpose.

Summarize

The real strength of Dmalloc is its configurable options. And highly portable, it has been successfully ported to various operating systems such as AIX, BSD/OS, DG/UX, Free/Net/OpenBSD, GNU/Hurd, HPUX, Irix, Linux, MS-DOG, NeXT, OSF, SCO, Solaris, SunOS, Ultrix, Unixware and even Unicos (running on a Cray T3E mainframe). While using Dmalloc requires a lot of learning, the features it provides are worth the price.

Electric Fence

Developer : Bruce Perens

Evaluation version : 2.2.3

Supported Linux Versions : All Kinds

License : GPL v2

Electric Fence is a memory debugging tool developed by Bruce Perens. It is implemented as a library, and your program needs to link it. Electric Fence can detect heap memory overflow and access to freed memory.

Electric Fence

Electric Fence

As the name implies, Electric Fence establishes a virtual fence at the boundary of each cache applied, so that any illegal memory access will cause a segmentation fault . This debugging tool supports both C and C++ programs.

Update details

Version 2.2.3 fixes the tool's build system so that -fno-builtin-mallocoptions can actually be passed to the GNU Compiler Collection (GCC) .

What are the advantages

The first thing I like about Electric Fence is that it is different from Memwatch, Dmalloc and Mtrace. You don't need to make any changes to your source code, you only need to link its library into your program at compile time.

Second, the Electric Fence implementation guarantees that the first instruction that produces an out-of-bounds access will cause a segmentation fault. This is much better than finding the problem later.

Electric Fence produces a copyright message in the output regardless of whether any errors are detected. This is very useful, so you can be sure that the program you are running has Electric Fence enabled.

Precautions

On the other hand, what I really miss about Electric Fence is its ability to detect memory leaks. Memory leaks are one of the most common and least-obvious problems in C/C++ software. However, Electric Fence cannot detect stack overflows and is not thread-safe.

Because Electric Fence will allocate prohibited virtual memory pages before and after the user allocates the memory area, if you perform too much dynamic memory allocation, your program will consume a lot of extra memory.

Another limitation of Electric Fence is that it cannot clearly indicate the line number of the error code. All it can do is segfault when it detects a memory-related error. If you want to locate the wrong line number, you need to use a debugging tool such as GDB to debug the program with Electric Fence enabled.

Finally, although Electric Fence can detect most buffer overflows, there is an exception that if the requested buffer size is not a multiple of the system word size, then the overflow (even if only a few bytes) cannot be detected come out.

Summarize

Despite its limitations, Electric Fence's ease of use is a plus. As long as the program is linked once, Electric Fence can report to the police when memory-related problems are detected. However, as mentioned earlier, Electric Fence needs to be used with a source code debugger like GDB.

Memcheck

Developer : Valgrind Development Team

Evaluation version : 3.10.1

Supported Linux Distributions : All Kinds

License : GPL

Valgrind is a suite that provides several tools for debugging and analyzing the performance of Linux programs. Although Valgrind can work with programs written in different languages—Java, Perl, Python, Assembly code, ortran, Ada, etc.—it is mainly aimed at programs written in C/C++.

Memcheck, a memory error detector, is the most popular of these tools. It detects issues such as memory leaks, invalid memory accesses, usage of undefined variables, and issues related to heap memory allocation and deallocation.

Update details

Toolkit (3.10.1) mainly fixes bugs found in version 3.10.0. Among other things, "some patches backported from the mainline development version, fixing missing AArch64 ARMv8 instructions and syscalls".

What are the advantages

Like all other Valgrind tools, Memcheck is a command-line program. Its operation is very simple: usually we use prog arg1 arg2commands such as the format to run the program, and Memcheck only requires you to add a few more values, such as valgrind --leak-check=full prog arg1 arg2.

Memcheck

Memcheck

-g(Note: Because Memcheck is the default tool of Valgrind, there is no need to mention Memcheck when executing commands on the command line. However, you need to bring parameter options at the beginning of the compilation program. This step will add debugging information, so that the error message of Memcheck will include correct line number.)

What I really like about Memcheck is that it provides a lot of command line options ( --leak-checkoptions mentioned above) so that you can control not only how the tool behaves but also its output.

For example, --track-originsthe option can be turned on to view uninitialized data in the program source code; --show-mismatched-freesthe option can be turned on to let Memcheck match memory allocation and deallocation techniques. For code written in C language, Memcheck will ensure that only free()functions can be used to release memory and malloc()functions to apply for memory. For the source code written in C++, Memcheck will check whether the deleteor delete[]operator is used to release memory, and newor new[]to apply for memory.

The best feature of Memcheck, especially for beginners, is that it advises the user which command-line options to use to make the output more meaningful. For example, if you don't use the basic --leak-checkoptions, Memcheck will suggest in the output: "Rerun with --leak-check=full to see more leaked memory details". If the program has uninitialized variables, Memcheck will produce the message: "use --track-origins=yes to see the origin of uninitialized variables".

Another useful feature of Memcheck is that it can createsuppress file suppression files , so that specific uncorrectable errors can be skipped, so that Memcheck won't warn every time it runs. It is worth mentioning that Memcheck will read the default suppression file to ignore errors in system libraries (such as C library), which exist before the system is created. You can choose to create a new suppression file, or edit an existing file (usually /usr/lib/valgrind/default.supp).

Memcheck also has advanced features, such as the ability to use a custom memory allocator to detect memory errors . In addition, Memcheck provides monitoring commands , which can be used when using Valgrind's built-in gdbserver and the client request mechanism (not only can inform Memcheck of the program's behavior, but also can query).

Precautions

There is no doubt that Memcheck can save a lot of debugging time and a lot of trouble. But it uses a lot of memory, causing program execution to slow down ( about 20 to 30 times longer, according to the documentation ).

In addition, Memcheck has other limitations. According to user comments, Memcheck is clearly not thread-safe ; it cannot detect static buffer overflows ; and, moreover, some Linux programs such as GNU Emacs do not currently work with Memcheck.

If interested, a detailed description of the limitations of Valgrind can be found here .

Summarize

Memcheck is a handy memory debugging tool for both beginners and those who need advanced features. If you just need basic debugging and error checking, Memcheck is very easy to get started. And when you want to use features like suppress files or watch commands, it takes some learning.

While listing numerous limitations, Valgrind (including Memcheck) claims on its website that the tool is used by thousands of programmers worldwide. The development team claims to have received feedback from users in more than 30 countries, and some of these users' engineering codes are as high as 25 million lines.

Memwatch

Developer : Johan Lindh

Evaluation version : 2.71

Supported Linux Distributions : All Kinds

License : GNU GPL

Memwatch is a memory debugging tool developed by Johan Lindh, although it plays the main role as a memory leak detector, but (according to the web page introduction) it also has the ability to detect other things such as memory double release and error release, buffer overflow and underflow , wild The ability to write pointers and other memory-related issues.

Memwatch supports programs written in C language. It is also possible to use it in C++ programs, but this practice is discouraged (as seen in the Q&A file accompanying the Memwatch source package).

Update details

This release adds ULONG_LONG_MAXto distinguish between 32-bit and 64-bit programs.

What are the advantages

Like Dmalloc, Memwatch has excellent documentation. Refer to the USING file, you can learn how to use Memwatch, you can understand how Memwatch is initialized, how to clean up, how to perform I/O operations, and so on. There is also an FAQ file designed to help users solve general problems encountered during use. There is also a test.cdocument at the end that provides working case references.

Memwatch

Memwatch

Unlike MTrace, the log files produced by Memwatch are (usually memwatch.log) in a human-readable format. Also, Memwatch will always splice the memory debug results to the end of the output file each time it is run. This makes it easy to review previous output information should the need arise.

It's also worth mentioning that when you execute a program that enables Memwatch, Memwatch will produce a single line on standard output saying that an error was found, and you can then view the output details in the log file. If no error messages are generated, you can ensure that no errors are written to the log file, and running it multiple times can really save time.

Another advantage I like is that Memwatch also provides a way to get its output information in the source code, you can get the information, and let it do what you want (see the function in the Memwatch source code for more information on this) mwSetOutFunc().

Precautions

Like Mtrace and Dmalloc, Memwatch also requires you to add code to your source files: you need to include memwatch.hthis header file in your code. Moreover, when compiling the program, you need to memwatch.ccompile together; or you can include the compiled object module, and then define MEMWATCHand MW_STDIOvariables on the command line. Needless to say, the -g compiler option is indispensable for locating line numbers in the output.

Also, Memwatch lacks some features. For example, Memwatch cannot detect a write operation to a block of memory that has been freed, or a read operation outside the allocated memory block. Also, Memwatch is not thread safe. Also, as I pointed out at the beginning, the results of running Memwatch on a C++ program are unpredictable.

Summarize

Memcheck can detect many memory-related problems and is a very handy debugging tool when dealing with C programs. Because the source code is small, you can understand how Memcheck works, debug it if necessary, and even expand and upgrade its functions according to your own needs.

Mtrace

Developers : Roland McGrath and Ulrich Drepper

Evaluation version : 2.21

Supported Linux Distributions : All Kinds

License : GNU GPL

Mtrace is a memory debugging tool in the GNU C library , which supports both C and C++ programs on Linux, and can detect memory leaks caused by functions malloc()and free()mismatched calls.

Mtrace

Mtrace

Mtrace actually implements a mtrace()function named mtrace, which can trace all malloc/free calls in the program and record relevant information in the file specified by the user. The files record data in a machine-readable format, so a Perl script -- also named mtrace -- is used to convert the files into a human-readable format.

Update details

The MTrace source code and Perl documentation are released together with the GNU C library (version 2.21), with no changes other than an updated copyright date.

What are the advantages

The best thing about MTrace is that it is very easy to learn. mtrace()You just need to know how and where to add and the corresponding functions in your source code muntrace(), and how to use MTrace's Perl script. The latter is very simple and only needs to run the command mtrace <program-executable> <log-file-generated-upon-program-execution>(see the last command in the screenshot at the beginning for an example).

Another advantage of MTrace is its scalability, which is reflected in the fact that it can be used not only to debug complete programs, but also to detect memory leaks in individual modules of a program. mtrace()Just call and in each module muntrace().

Last but not least, because MTrace is mtrace()triggered when - a function added in the source code - is executed, it is very flexible to use signals to enable MTrace dynamically (while the program is executing).

Precautions

Because mtrace()calls to mauntrace()functions—declared in mcheck.hfiles, so the header file must be included in the source code—are fundamental to the work of MTrace ( mauntrace()functions are not always necessary ), MTrace requires the programmer to change the source code at least once.

It should be noted that when compiling the program, bring the -g option (both GCC and G++ compilers provide it), so that the debugging tool can display the correct line number when outputting the result. Besides, some programs (depending on how big the source code is) may take a long time to compile. Finally, compiling with the -g option increases the size of the executable (because of the extra debug information provided), so remember that the program needs to be recompiled without the -g option after testing.

To use Mtrace, you need to master the basic knowledge of Linux environment variables, because before the program is executed, the user needs to set the MALLOC_TRACEvalue of the environment variable to the path of the specified file ( mtrace()the function will record all information into it).

Mtrace has limitations in detecting memory leaks and attempts to free unallocated memory. It cannot detect other memory related issues such as illegal memory access, use of uninitialized memory. Also, there are complaints that Mtrace is not thread-safe .

Summarize

It goes without saying that each of the memory debuggers I've discussed here has its strengths and limitations. So, which one is right for you depends on the features you need, although sometimes ease of installation and use is also a deciding factor.

Mtrace is perfect for catching memory leaks in software programs. It also saves time. Since the Linux system has pre-installed this tool, Mtrace is also very helpful for situations where the Internet cannot be connected or third-party debugging tools cannot be downloaded.

On the other hand, compared to Mtrace, Dmalloc not only can detect more error types, but also provides more features, such as runtime configuration and GDB integration. Also, Dmalloc, unlike the other tools mentioned here, is thread-safe. Not to mention its detailed profile, which makes Dmalloc ideal for beginners.

Although Memwatch has more information than Dmalloc and can detect more types of errors, you can only use it in programs written in C language. One feature that makes Memwatch stand out is that it allows you to handle its output in your program source code, which is very useful if you want to customize the output format.

If changing the program source code is not your wish, then use Electric Fence. However, keep in mind that Electric Fence can only detect two types of errors, neither of which are memory leaks. Also, a basic understanding of GDB is required to maximize the utility of this memory debugging tool.

Memcheck is probably the most comprehensive of the bunch. It detects more error types, provides more features than any other tool mentioned here, and doesn't require any changes to your source code. But please note that the basic functions are not difficult to use, but if you want to use its advanced features, you must learn relevant professional knowledge.


via: http://www.computerworld.com/article/3003957/linux/review-5-memory-debuggers-for-linux-coding.html

Guess you like

Origin blog.csdn.net/sukeeeeeeeee/article/details/53885617
Recommended