Discussion on the solution of memory leakage problem in ATS plug-in development

Contact ATS has been developed for several years, developed kernel modules, also engaged in the development of plug-ins. Memory leaks have been a headache for most ATS developers, Let's talk about my own feelings and thoughts. Here is the topic of ATS plugin development. The source code of the example and plugins directory of the different business scenarios of the plug-in instances, many of us have a very big inspiration, but there are some problems, especially the problem of cache leaks, It is common in the sample plug-in given by example.
The risk of memory leaks handled by MIME field in 1.http header
ATS plug-ins are mainly added in each HTTP transaction interaction in the specified phase of the hook API, commonly known as "hooks". For example, in the following hooks
For this reason we have to deal with the requirements of the business logic, the HTTP request header and HTTP response header of the various Host,url,status code,mime field, such as acquisition, modification, addition, deletion and other operations, According to the source code in example, the various exception handling is not very comprehensive, in the production environment running in the risk of memory leaks.

One solution to this risk is to use a lot of do{...} while (0), consider the example of the following two-segment code

Visible from above, do{...} while (0) many solved the abnormal situation exit function of the resource release problem, a large reduction of duplicate program statements, code is more robust, more concise.


2. Create a memory leak risk caused by releasing memory when you introduce an external library yourself
I used to introduce the Tsiobuffer class of memory pool management containers in plugins to avoid calling Tsmallac () and Tsfree () to release memory frequently, but after careful investigation of the Code, I found that the interface provided by Tsiobuffer is only for small memory within 4096 char* read-out conversion processing, for a size of about 300K HTML page, using Tsiobuffer a class of memory pool management is not appropriate. I also studied Nginx memory. Pool of ideas, found that the memory pool management is also targeted for small memory within 4096. For large memory, ATS and Nginx are directly allocated and freed by calling malloc and free internally.
So there is a risk that such a large amount of memory, if in exceptional cases, is not released, will lead to a great risk of memory leaks, how to solve this problem?
For example, I would like to make a regular match to the HTML of the URL of a certain class of the specified rule, change its internal HTML code, such as a JS link address, I inevitably need to go through the following steps:

Get HTML full content from upstream ==> extract =>pcre regular find and replace + = Compress = Update content-length header domain = write downstream

In this process, decompression and compression, pcre find replacement involves allocating a large amount of memory, if there is an exception in this process, the memory allocated before the release is very dangerous. I explored a method of using HTTP transaction to manage memory internally. is to create a memory management single-linked list, the flow of all the memory that needs to be dynamically allocated in this single-linked list of mountains, to exit the process, one-time release of the single-linked list of dynamically allocated memory, this method is a good solution to their own application to release memory problems.

Here is the plugin memory tune attempt