<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">There is a good graphical tool for tracing called Erlyberly that you should look at:<div class=""><br class=""></div><div class=""><a href="https://github.com/andytill/erlyberly" class="">https://github.com/andytill/erlyberly</a></div><div class=""><br class=""></div><div class="">It would be good to get some Elixir users on it too to work out how to do tracing into the Elixir function name space properly…</div><div class=""><br class=""></div><div class="">Gordon</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 21 sept. 2015 à 11:02, Ulf Wiger <<a href="mailto:ulf@feuerlabs.com" class="">ulf@feuerlabs.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 21 Sep 2015, at 10:52, Lukas Larsson <<a href="mailto:lukas@erlang.org" class="">lukas@erlang.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">To start the discussion, here are a few of my ideas in no particular order:</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> * Allow multiple tracers. Today only one port/process can be the receiver of trace data.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> * Create a couple of scalable high throughput tracing output backends with different overflow mechanics. Today all tracing is funneled through one bottleneck and has no overflow handling at all.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> * Expose vm probes (today dtrace probes) to the erlang tracer.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> * Better integration of dtrace/lttngt/systemtap into the erlang trace.<br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> * Allow the erlang tracer to be an Erlang callback module. Today only ports/processes are allowed.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> * Optimize trace output to file/ip. Maybe use something like the Common Trace Format (<a href="http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-specification.md;hb=master" class="">http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-specification.md;hb=master</a>), instead of the term_to_binary that we have today.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> * Write much much better documentation for dbg :)</div></div></blockquote><br class=""></div><div class="">+1 on the suggestions, esp. multiple tracers. The one-tracer restriction makes it hard to explore some very interesting monitoring and debugging ideas.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">See e.g. the locks application:</div><div class=""><a href="https://github.com/uwiger/locks/blob/master/src/locks_leader.erl#L140" class="">https://github.com/uwiger/locks/blob/master/src/locks_leader.erl#L140</a></div><div class=""><a href="https://github.com/uwiger/locks/blob/master/src/locks_leader.erl#L823" class="">https://github.com/uwiger/locks/blob/master/src/locks_leader.erl#L823</a></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">So basically, the features are:</div><div class="">- a ‘debug’ function that is as lightweight as possible when not traced, just existing for the purpose of being traced</div><div class="">- including line numbers</div><div class=""><br class=""></div><div class="">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 <a href="https://github.com/uwiger/locks/blob/master/src/locks_ttb.erl" class="">https://github.com/uwiger/locks/blob/master/src/locks_ttb.erl</a> (Logs fetched only if test case fails).</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">To further generalize the issue …</div><div class=""><br class=""></div><div class="">What we ended up with at Ericsson was a variety of techniques for getting the most out of tracing:</div><div class=""><br class=""></div><div class="">- 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.</div><div class="">- 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><a href="http://jlouisramblings.blogspot.se/2011/10/using-event-tracer-tool-set-in-erlang.html" class="">http://jlouisramblings.blogspot.se/2011/10/using-event-tracer-tool-set-in-erlang.html</a></div><div class=""><a href="http://souja.net/2009/04/making-sense-of-erlangs-event-tracer" class="">http://souja.net/2009/04/making-sense-of-erlangs-event-tracer</a></div><div class=""><a href="http://sysmagazine.com/posts/131140/" class="">http://sysmagazine.com/posts/131140/</a></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">BR,</div><div class="">Ulf W</div><br class=""><div apple-content-edited="true" class="">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><div class=""><div class="">Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.</div><div class=""><a href="http://feuerlabs.com/" class="">http://feuerlabs.com</a></div></div><div class=""><br class=""></div></span><br class="Apple-interchange-newline">
</div>
<br class=""></div>_______________________________________________<br class="">erlang-questions mailing list<br class=""><a href="mailto:erlang-questions@erlang.org" class="">erlang-questions@erlang.org</a><br class="">http://erlang.org/mailman/listinfo/erlang-questions<br class=""></div></blockquote></div><br class=""></div></body></html>