Erlang Central

Tracing Processes

Revision as of 23:22, 25 June 2008 by Marstein (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Say you have written an application and want to find out what is happening when things don't work like they should.

In my case I have put
et:report_event(60, caller, callee, operation, [data])
into my source at strategic places. The ET manual tells you that, but they are not very clear how to get to that stuff.
% Start a tracer process.
dbg:tracer().
	
% trace all items.
dbg:p(all, call).
	
% trace locally the report_event function we use to report transaction times.
dbg:tpl(et, report_event, 5, []).

the dbg:p() function tells the tracer process that we are planning to trace calls. tpl then tells the tracer which functions exactly to trace. This can be narrowed down by a match specification (the empty list at the end of dbg:tpl). This is a hairy thing, like a chemical formula, but less readable, to say exactly what variables and pieces of code exactly you want to see. I leave it empty.

The above lines, executed in the erl shell after starting the application make that every time et:report_event is executed a line like
(<0.235.0>) call et:report_event(60,mnesia_tm,server,post,[{from,{<0.66.0>,#Ref<0.0.0.1839>}},{microsecs,10521}])
is printed.


It is possible to modify each step of the trace, of course, but it is complex and easy to do it wrong.


There are a ton of tools in Erlang: et, Observer and ttb that make tracing 'easier'. They need cookbook entries!