Shulou(Shulou.com)06/01 Report--

This article will explain in detail about the principle and design of lua memory leak detection tools, the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Google "lua memory leak detection" basically points directly or indirectly to "an Lua memory leak detection tool" written by Yunfeng many years ago. The idea is to take a snapshot of the virtual machine, record all gc object addresses and reference relationships, and then analyze memory leaks by comparing the two snapshots. The article seems to equate memory leaks with the addition of a gc object.

However, does the addition of gc objects represent a memory leak? Take a look at this code:

Local no_leak = {} function innocent () no_leak.a = {x = 1} no_leak.b = {y = 1} end

Each time the innocent function executes, it adds two new table and holds them, but this is obviously not a memory leak, and this is a common way to write it.

No new gc object means no memory leak? Nor is it:

Local local_leak = {} function make_leak () table.insert (local_leak, 1) end

The tools provided by this leaked article seem powerless. It only records the reference relationships between gc objects and gc objects. But numbers are not gc objects.

Memory leak with GC language

The memory leak in languages such as CAccord Clipper + is that the memory is allocated and forgot to be freed, but GC will help us automatically free this kind of memory. A memory leak in a language with GC is stuffing something into a container and forgetting to delete it.

What happens if you put something in a container and forget to delete it?

Of course, it causes the container to become larger, so suspected memory leak detection becomes container size (incremental) detection.

This is very simple in lua, because. Lua has only one container-- table.

Lua memory leak check

The core code is very simple, with only about a dozen lines of C code:

Typedef void (* TableSizeReport) (const void * p, int size); LUA_API void xlua_report_table_size (lua_State * L, TableSizeReport cb, int fast) {GCObject * p = G (L)-> allgc;while (p! = NULL) {if (p-> tt = = LUA_TTABLE) {Table * h = gco2t (p); cb (h, table_size (h, fast));} p = p-> next;}}

Iterate through all objects and, if it is table, report the pointer and size to the caller.

This C code will be called by C # and record the size information of table, which is also very simple:

Static Data getSizeReport (LuaEnv env) {Data data = new Data (); data.Memroy = env.Memroy; LuaDLL.Lua.xlua_report_table_size (env.L, (IntPtr p, int size) = > {data.TableSizes.Add (p, size);}, 0); return data;}

All right, then compare the size information before and after, you can find out the pointer to the table that may have a memory leak. No code will be posted here. All the code in the article can be found in the xLua open source project.

Table details

It's no use just taking the pointer of table. We need to get more information before we locate it.

Generally speaking, table goes up its citation chain and boils down to three places:

1. Upvalue, such as local xx = {} defined in the lua script

2. Global variables

3. A special table:registry shared by c side

Of course, the stack may also refer to table, but we are calling C code in C #, at that time did not run lua, the stack should be empty, and only the stack points to the object, we can ignore the object, this object is either temporary, or later is still referenced by the above three places.

Table details ideas

1. Get the object reference relationship and generate the reverse index table

2. Find the suspected leaked table from the reverse index table, then look up according to the reverse index, always find the above three roots, and generate the path.

A typical leak report goes like this:

Total memroy: 87potential leak in {leak2.lua:local anthor_leak.a [1] .b, _ R.ref_anthor_leak.a [1] .b} potential leak (181b) in {_ G.global_leak} potential leak (180) in {leak1.lua:local local_leak}

The first line indicates that there is a suspected leak table of size 180, which is referenced in two places

One is the local variable anthor_leak of the leak2.lua file, which is located in the a [1] .b child node of this local variable.

One is the registry table (the third place above), the ref_anthor_leak.a [1] .b child node

Fast leakage and slow leakage

If there is a quick leak and a slow leak in the program, we compare table size information twice and can be ignored because it didn't go up.

It doesn't matter, when you find the place where the leak is fast, the fast one and the slow one can be detected.

Test examples also show this situation.

On the lua memory leak detection tool principle and design is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.