Re: lua traceback during memory allocations
- From: "Yichun Zhang (agentzh)" <agentzh@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 14 Mar 2014 16:22:33 -0700
Hello!
On Fri, Mar 14, 2014 at 12:57 PM, Greg Greenway wrote:
> I'm trying to add some tracking of lua allocations to help figure out where
> I'm "leaking" memory in my code. (It's not technically a leak in the strict
> sense because something is referencing it).
>
I think the lj-gc-objs tool based on systemtap can help analyzing such
leaked Lua GC objects:
https://github.com/agentzh/stapxx#lj-gc-objs
Just look at the type of GC objects with largest size, or the count.
And we can trace further based on the findings.
> My basic approach is to add a function call right after the allocation of
> strings, tables, functions, etc (in C code) and store a lua backtrace at
> that time and store it with the allocated pointer in a hash table. When
> memory is free'd, I remove the entry. Periodically, I look at what's in the
> table and look for a growing number of occurrences of the same callstack.
>
This sounds like the idea of my "memory leak" flame graph tool for C/C++ apps:
https://github.com/agentzh/stapxx#sample-bt-leaks
You can update the tool to probe on LuaJIT's allocator functions and
collect Lua backtraces (as in the lj-lua-stacks tool:
https://github.com/agentzh/stapxx#lj-lua-stacks ).
> My problem is that sometimes while trying to generate the backtrace, I get a
> SEGV. My code for getting a traceback is:
>
The LuaJIT VM may not always be in a consistent state for your to call
userland C functions. You'd better use external tools like systemtap
(as mentioned above) and gdb. In gdb, I also wrote the "lbt" command
in Python to get the Lua backtraces:
https://github.com/agentzh/nginx-gdb-utils#lbt
Though the gdb tools are better for core dump analysis rather than
runtime profiling :) systemtap (or dtrace) is the best option for
analyzing live processes.
Best regards,
-agentzh
Other related posts:
