[erlang-questions] Erlang tracing

Lukas Larsson lukas@REDACTED
Mon Sep 21 13:46:39 CEST 2015


On Mon, Sep 21, 2015 at 12:02 PM, Ulf Wiger <ulf@REDACTED> wrote:

> I have had some success using an event/[2,3] function for lightweight
> debugging, where the functions event(Line, Event) and event(Line Event,
> State) exist only to be traced. A simple way to generalize this would be to
> create ‘null’ BIFs: erlang:trace_event(Info, Event) -> ok,
> erlang:trace_event(Info, Event, State) -> ok (just a trace_event/1 would of
> course suffice). If not traced, these functions do nothing; when traced,
> they emit trace info similar to io:format debugging.
> See e.g. the locks application:
> https://github.com/uwiger/locks/blob/master/src/locks_leader.erl#L140
> https://github.com/uwiger/locks/blob/master/src/locks_leader.erl#L823
So it should be possible define your own trace probes (for lack of a better
word) in erlang code? That is a very good point. For dtrace we have the
dyntrace module that you can put calls to with very little overhead. Maybe
something similar can be done for Erlang tracing? I don't think we should
step on the toes of logging though, as those (in my opinion) should be two
different things.

> The ?debug/[1,2] macro is used to also include line numbers. One could
> perhaps imagine such a macro existing in dbg, but putting an event()
> function in dbg as well forces a remote call even when tracing is not
> enabled.

Including the line number could be useful. Maybe adding it in the match
spec for the given trace pattern? Much in the same way as
{message,{process_dump}} works today?

> I’ve found this extremely useful not least when enabled during multi-node
> test suite execution, using ttb to merge logs and a final pretty-printing
> step to produce a text log best viewed with emacs's Erlang syntax
> highlighting. See
> https://github.com/uwiger/locks/blob/master/src/locks_ttb.erl (Logs
> fetched only if test case fails).
I had completely forgot about the ttb. Will have to read up on what you can
do with it.

> One might fantasize about enabling migration from io:format() debugging to
> this, ideally by simply rewriting the debug macro: a handy wrapper that
> simulates the original printouts. There are some problems with this, so
> I’ve chosen not to go there.
> To further generalize the issue …
> What we ended up with at Ericsson was a variety of techniques for getting
> the most out of tracing:
> - A script that inserted a ?DBG macro after each ->. This was a
> conditional debug printout, but could have been a trace event as above. The
> feature was to log the ‘branching’ in the code, e.g. noting which case
> function or receive clause was actually selected.
> - Consistently breaking out case clauses etc as separate functions (since
> function calls can be traced). See e.g. the diameter application in OTP for
> examples of this style of coding.

Tracing on all branches would indeed be neat to have. Not sure if it ever
will be possible to do in the emulator without instrumenting the code

> I think there is room for revisiting the ‘et’ concept in this context. The
> thing about ‘et’ was that it allowed for a ‘model-level’ trace, complete
> with sequence diagram presentation. Its main drawback was that few figured
> out how to use it. But I think the idea is brilliant: to be able to
> dynamically extract ‘model markers’ from executing code and displaying it
> in a way that can tie back to the conceptual design.
> http://jlouisramblings.blogspot.se/2011/10/using-event-tracer-tool-set-in-erlang.html
> http://souja.net/2009/04/making-sense-of-erlangs-event-tracer
> http://sysmagazine.com/posts/131140/

yet another tool I had forgotten about :) thanks for reminder!

> Lastly, TTB has been greatly improved (ahem…) and is extremely useful for
> multi-node tracing. When improving the DBG documentation, make sure to show
> how TTB and DBG work together and what their respective roles are.

We'll keep that in mind.

Thanks for your input!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150921/47bcebd6/attachment.htm>

More information about the erlang-questions mailing list