How to register mallocs

Question

This is a little hypothetically and roughly simplified, but ...

Suppose a program calls functions written by third parties. These parties may not be considered hostile, but may not be considered "competent." Each function takes some arguments, has side effects and returns a value. They have no status until they work.

The goal is to ensure that they cannot cause memory leaks by registering all mallocs (etc.), and then freeing everything after the function exits.

Is it possible? Is it practical?

ps An important role for me is to ensure that allocations are not preserved, so ways to remove memory leaks without this are not useful to me.

Answer 1

You do not specify an operating system or environment, this answer assumes Linux, glibc and C.

You can set __malloc_hook, __free_hook and __realloc_hook to indicate the functions that will be called from malloc (), realloc () and free (), respectively. There is a prototype __malloc_hook showing prototypes. You can add track allocations to these interceptors and then return so that glibc handles memory allocation / deallocation.

It looks like you want to free any live selections when a third-party function returns. There are ways for gcc to automatically insert calls every time a function is entered and exit using -finstrument-functions, but I think it would be impractical for what you are trying to do. Can you have your own code call a function in your memory tracking library after calling one of these third-party functions? Then you can check if there are any distributions that the third-party function has not yet released.

Answer 2

First you must specify entry points for malloc() and free() and friends. Since this code has already been compiled (right?), You cannot depend on #define to redirect.

Then you can implement them in an obvious way and record that they came from a specific module by linking these procedures to these modules.

The fastest way does not lead to registration at all. If the amount of memory that they use is limited, why not allocate all the “heap” they will ever need and write from this allocator? Then, when this is done, free the whole "bunch", and you're done! You can expand this idea to a few heaps if it is more complicated.

If you really need to log and not create your own dispenser, here are some ideas. First, use a hash table with pointers and an inner chain. Another would be to allocate additional space in front of each block and place there your own structure containing, say, an index in your “log table”, and then save a free list of log table entries (in the form of a stack to get free or put free back - O (1)). It takes up more memory but should be fast.

Is it practical? I think this is true if speed is acceptable.

Answer 3

You can run third-party functions in a separate process and close the process when you are done using the library.

Answer 4

A better solution than attempting to register mallocs might be to isolate the functions when they are called - to give them access to a fixed segment of memory, and then free this segment when the function is executed.

Unprofitable use of incompetent memory can be just as harmful as malicious code.

Answer 5

Can't you make them allocate all their memory on the stack? Thus, release after function exit will be guaranteed.

Answer 6

In the past, I wrote a C software library in which there was a memory management subsystem that contained the ability to logarithm distributions and releases and manually map each distribution to free. This was useful when trying to find memory leaks, but it was difficult and time consuming to use. The number of magazines was huge, and it took a long time to study the magazines.

Saying this, if your third-party library has extensive distributions, it is more likely not practical to track this by logging. If you work in a Windows environment, I would suggest using a tool like Purify [1] or BoundsChecker [2], which should be able to detect leaks in your third-party libraries. Investing in a tool should pay off in a short time.

[1]: http://www-01.ibm.com/software/awdtools/purify/ Clear

[2]: http://www.compuware.com/products/devpartner/visualc.htm BoundsChecker

Answer 7

Since you are concerned about memory leaks and talking about malloc / free, I assume you are in C. I also assume, based on your question, that you do not have access to the source code of a third-party library.

The only thing I can think of is to examine the memory consumption of your application before and after the call, report error messages if they are different, and convince a third-party vendor to fix any leaks that you find.

Answer 8

If you have money to save, consider using Purify to track issues. It works wonders and does not require source code or recompilation. There are other debugging malloc libraries available that are cheaper. Electric fence is one name that I remember. This suggests that the distracting hooks mentioned by Denton Gentry also seem interesting.

Answer 9

If you are too poor for Purify, try Valgrind. This is much better than it was 6 years ago, and much easier to dive than Purify.

Answer 10

Microsoft Windows provides (use SUA if you need POSIX), possibly the most modern heap infrastructure + (another api known for using heap) of any transport OS today.

The __malloc () debug hooks and their associated CRT debugging interfaces are good for cases where you have the source code for the tests, however they can often skip highlighting with standard libraries or other related code. This is expected because they are the Visual Studio heap debugging infrastructure.

gflags is a very detailed and detailed set of debugging features that have been included in Windows for many years. Having advanced functionality for source and binary files, they are used only (for example, the operating system debugging infrastructure).

It can record full stack traces (reproduction of symbolic information in the operation after processing), for all users of the heap, for all heaps that change the entry point, if necessary, if necessary. In addition, it can modify the heap with pathological cases that can even out data distribution so that the page protection offered by the VM system is optimally assigned (i.e., it allocates your requested heap block at the end of the page, so even a single byte overflow is detected during overflow.

umdh is a tool that can help evaluate the status at different control points, however, data is constantly accumulated during the execution of the goal o this is not a simple stop to debug a checkpoint in a traditional context. In addition, a WARNING. The last thing I checked, at least the total size of the circular buffer that stores information about the stack, for each request is somewhat small (64 thousand records (records + stack)), so you may need to quickly dump large heap users. There are and other ways to access this data, but umdh is pretty simple.

NOTE there are 2 modes;

• MODE 1, umdh {-p: Process-id | -pn: ProcessName} [-f: Filename] [-g]

• MODE 2, umdh [-d] {File1} [File2] [-f: Filename]

  I don’t know what kind of frenzy swept the developer who chose the alternative option -p: foo the argument argument and the bare order of the argument, but it can be a bit confusing.

Debugging sdk works with a number of other tools, memsnap is a tool that seems to focus on the sheet for storage, etc., but I haven’t used it, your movement may change.

To execute gflags with no arguments for user interface mode, + arg and / args are also used in different modes.