Diagnosing Leaks in Native Code

本文摘自sun.com网站分析Diagnosing Leaks in Native Code

 

3.4 Diagnosing Leaks in Native Code

Several techniques can be used to find and isolate native code memory leaks. In general there is no single ideal solution for all platforms.

3.4.1 Tracking All Memory Allocation and Free Calls

A very common practice is to track all allocation and free calls of the native allocations. This can be a fairly simple process or a very sophisticated one. Many products over the years have been built up around the tracking of native heap allocations and the use of that memory.

Tools like Purify and Sun's dbx Run Time Checking (see 3.4.4 Using dbx to Find Leaks ) functionality can be used to find these leaks in normal native code situations and also find any access to native heap memory that represents assignments to uninitialized memory or accesses to freed memory.

Not all these types of tools will work with Java applications that use native code, and usually these tools are platform-specific. Since the virtual machine dynamically creates code at runtime, these tools can wrongly interpret the code and fail to run at all, or give false information. Check with your tool vendor to make sure the version of the tool works with the version of the virtual machine you are using.

Many simple and portable native memory leak detecting examples can be found at http://sourceforge.net/ . Most of these libraries and tools assume that you can recompile or edit the source of the application and place wrapper functions over the allocation functions. The more powerful of these tools allow you to run your application unchanged by interposing over these allocation functions dynamically. This is the case with the library libumem.so , starting with Solaris 9 OS update 3; see 3.4.5 Using libumem to Find Leaks .

3.4.2 Tracking Memory Allocation in a JNI Library

If you write a JNI library, it would probably be wise to create some kind of localized way to make sure your library does not leak memory, using a simple wrapper approach.

The following procedure is an easy localized allocation tracking approach for a JNI library. First, define the following lines in all source files:

#include <stdlib.h>
#define malloc(n) debug_malloc(n, __FILE__, __LINE__)
#define free(p) debug_free(p, __FILE__, __LINE__)

 

Then you can use the following functions to watch for leaks.

/* Total bytes allocated */
static int total_allocated;
/* Memory alignment is important */
typedef union { double d; struct {size_t n; char *file; int line;} s; } Site;
void *debug_malloc(size_t n, char *file, int line) 
{     char *rp;
rp = (char*)malloc(sizeof(Site)+n)；
total_allocated += n;     
((Site*)rp)->s.n = n;    
((Site*)rp)->s.file = file;    
((Site*)rp)->s.line = line;    
return (void*)(rp + sizeof(Site));
}
void debug_free(void *p, char *file, int line)
{    
char *rp;    
rp = ((char*)p) - sizeof(Site);    
total_allocated -= ((Site*)rp)->s.n;
free(rp);
}

 

The JNI library would then need to periodically (or at shutdown) check the value of the total_allocated variable to make sure that it made sense. The above code could also be expanded to save in a linked list the allocations that remained and report where the leaked memory was allocated. This is a localized and portable way to track memory allocations in a single set of sources. You would need to make sure that debug_free() was called only with a pointer that came from debug_malloc() , and you would also need to create similar functions for realloc() , calloc() , strdup() , and so forth, if they were used.

A more global way to look for native heap memory leaks would involve interposition of the library calls for the entire process.

3.4.3 Tracking Memory Allocation With OS Support

Most operating systems include some form of global allocation tracking support.

·         On Windows, go to http://msdn.microsoft.com/library/default.asp and search for debug support. The Microsoft C++ compiler has the /Md and /Mdd compiler options that will automatically include extra support for tracking memory allocations.

·         Linux systems have tools such as mtrace and libnjamd to help in dealing with allocation tracking.

·         Solaris Operating Systems provide the watchmalloc tool. Solaris 9 OS update 3 started providing the libumem tool (see 3.4.5 Using libumem to Find Leaks ).

3.4.4 Using dbx to Find Leaks

The Sun debugger dbx includes the Run Time Checking (RTC) functionality, which can find leaks. The dbx debugger is also available on Linux.

Below is a sample dbx session.

The output shows that the dbx debugger reports memory leaks if memory is not freed at the time the process is about to exit. However, memory that is allocated at initialization time and needed for the life of the process is often never freed in native code. Therefore, in such cases the dbx debugger can report memory leaks that are not leaks in reality.

Note that the example used two suppress commands to suppress the leaks reported in the virtual machine (libjvm.so ) and the Java support library (libjava.so ).

3.4.5 Using libumem to Find Leaks

Starting with Solaris 9 OS update 3, the libumem.so library and the modular debugger (mdb ) can be used to debug memory leaks. Before using libumem , you must preload the libumem library and set an environment variable as follows:

Now, run the Java application but stop it before it exits. The following example uses truss to stop the process when it calls the _exit system call:

At this point you can attach the mdb debugger, as follows:

 

The ::findleaks command is the mdb command to find memory leaks. If a leak is found, the findleaks command prints the address of the allocation call, buffer address, and nearest symbol.

It is also possible to get the stack trace for the allocation which resulted in the memory leak by dumping the bufctl structure. The address of this structure can be obtained from the output of the ::findleaks command. The description of the commands to perform these functions, as well as more information on using libumem to identify memory managements bugs, is located at the following address: http://access1.sun.com/techarticles/libumem.html .