[erlang-questions] Erlang tracing

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Mon Sep 21 23:15:04 CEST 2015

On Mon, Sep 21, 2015 at 8:58 PM, Michael L Martin <mmartin4242@REDACTED>

> If that's already possible, I couldn't find a way to do it.

[I do have comments, but this question warrants an answer]

You can do this via 'dbg', because it is the same calls you have to make.
The  problem is you need to set up call tracing on the functions for which
you are interested. And you also need to set up which pids it affects. The
intersection, i.e., the marked pids which calls the marked functions, will
output trace patterns:



g() -> 37.

f() ->
    dbg:tracer(), %% Construct a tracer
    dbg:p(self(), call), %% Call tracing for ourselves enabled
    dbg:tpl(z, g, 0, cx), %% Set a tracepoint for a local function, enable
caller/exception trace flags for it
    dbg:stop_clear(). %% Get rid of the tracer again

; erl
Eshell V7.0.3  (abort with ^G)
1> c(z).
2> z:f().
(<0.33.0>) call z:g() ({z,f,0})
(<0.33.0>) returned from z:g/0 -> 37

though the dbg interface is unwieldy, it does provide a lot of power. A
simpler and safer solution is Fred Hebert's recon library:

f() ->
    recon_trace:calls({z, g, fun(_) -> return_trace() end}, 10, [{scope,

Simpler interface, but also less powerful. I tend to use both.

The power is the dynamic tracing capabilities. You can enable them on
production systems as you inspect them. If tracing is enabled through
recompilation, you have to mess with the injected modules on the running
system. Very good for debugging, but your operations department will hate
you for the fact that they don't know which code is currently executing on
their system.

That said, however, a simpler debug-tracing interface is not a bad idea I
think. Anything that can help programmers build robust code.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150921/331755ef/attachment.htm>

More information about the erlang-questions mailing list