[erlang-questions] [ANN] Recon 2.1.0 released

Fred Hebert <>
Tue Mar 4 16:46:01 CET 2014


Hi everyone,

I've just released recon 2.1.0, a library to debug dand diagnose Erlang
production systems.

The biggest addition here is the addition of `recon_trace', to try and
allow safe tracing, in production. It's a bit similar in intent to
redbug (without the dependency chain), and tries to be more powerful.

Example usage:

    1> recon_trace:calls({queue, '_', fun([A,_]) -> return_trace() end}, {10,100}).
    32
    
    13:24:21.324309 <0.38.0> queue:in(3, {[],[]})
    
    13:24:21.371473 <0.38.0> queue:in/2 --> {[3],[]}
    
    13:25:14.694865 <0.53.0> queue:split(4, {[10,9,8,7],[1,2,3,4,5,6]})
    
    13:25:14.695194 <0.53.0> queue:split/2 --> {{[4,3,2],[1]},{[10,9,8,7],[5,6]}}
    
    2> recon_trace:clear().
    ok

This matches all functions from the queue module with an arity 2, and
returns the result of the call. It also puts a practical limit of 10
trace messages per 100 milliseconds.

There's more stuff in there:

- Limiting to an absolute count or a rate over time
- Matching on arity only
- Matching on multiple specs
- Allowing to match on existing, new, all pids, or one or more processes
  (of the form <A.B.C>, {A,B,C}, "<A.B.C>", some_name, {global, Name},
  {via, gproc, Name}, etc.)
- Printing traces with arities or arguments
- tracing local function calls (see f(X), not mod:f(X))

There's also protection against annoying errors:

- wildcard matches on modules banned unless restricting the
  arguments
- don't trace IO, lists, or recon_trace itself
- Each call to `recon_trace:calls' resets the trace patterns to
  avoid adding more specs than expected
- Linked to the calling process so that a disconnected node or crashed
  shell turns of tracing on the remote node

For the time being, only function calls are being traced -- GC, message
passing, and scheduling aren't included. I hope this is still going to be
useful to Erlang devs around!

Full Documentation: http://ferd.github.io/recon/recon_trace.html
Source: https://github.com/ferd/recon

Regards,
Fred.



More information about the erlang-questions mailing list