Erlang Testing and Debugging
Target Audience: Support and Test Engineers, Software Developers,
Prerequisites: Erlang programming and testing experience. No OTP is necessary.
Objectives: Understand the test and debug strategies needed in finding bugs. Understanding of the debugging primitives so as to be able to implement own tools. Knowledge on the debugging tools available.
Duration: One day
This one-day course gives insight in the less known trace tools and mechanisms available in Erlang. Its contents are up to date with all the latest features in the language, including the trace BIF alongside the so ugly, yet so useful match specifications. Its target audience consists of programmers, testers and support engineers with a few months Erlang experience. Having attended the OTP course is not a requirement. The course contains hand on exercises where users write their own tools to test, monitor and profile the system, or adapt existing tools to a set of predefined requirements. Note that the contents of this course are included in the five day Erlang introductory course for testers and support engineers.
Please note the course will take TWO DAYS with exercises.
Modules and Processes
Crash dumps are files generated whenever the Erlang run time systems terminates abnormally. This section describes how these files can be read so as to understand what caused the termination of the virtual machine. The most common terminations are due to physical constraints such as running out of memory or having too many atoms or ets tables in the system. Interpreting the crash dumps is important as in most cases, the emulator or the operating systems can be reconfigured so as to avoid the crash. Should the termination occur because of running out of memory, the crash dump file can point out how large the heap and the stacks of all the processes are, providing valuable clues to where the problem is located.
Modules and Processes
The first section of the course looks at how to retrieve information on processes and modules. The bifs used to retrieve system information can be used to gather information which might give clues in solving a bug or help profile the system. The information includes process states, process heaps (backtraces), call chains as well as memory and processor usage. This data is available even after a process has been terminated through so called 'zombie processes'. This section describes how to activate zombie processes and retrieve information from them.
Trace bifs provide a low level trace mechanism. The fact that it can be used with out trace compiling the code makes it useful when tracing garbage collecting, memory consumption, message passing, and other process activities including local and global function calls. This section looks at how to activate and deactivate the different trace flags as well as turning them on for different processes, modules and functions. The understanding of the trace and trace_pattern bifs are important as they give an insight into what exactly is available for low level debugging and are used to build many of the existing tools.
The dbg Tool
The dbg tool is a text based debugger providing a friendly interface to the trace bifs with small impacts on system performance. This section introduces the tool and covers how this tool can be used in a distributed environment or how the output can be redirected on other nodes, log files, ports and sockets.
This section covers match specifications, an Erlang term providing a low level mechanism which will match and test the arguments passed to traced function calls. If the match is successful, a trace message is issued along side possible user defined events. These match specifications are very powerful in that they allow conditional tracing on specific function calls based on the arguments with out having to recompile or change the code. Due to its neglectable impact on system performance, if used with care, match specifications can be used to detect bugs on live systems.
Sequential tracing is a way to trace a sequence of messages sent between different local or distributed processes where the sequence is initiated by one single event. This section looks at how sequential tracing works, and where it can be used.