Erlang Programming

Chapter 17. Trace BIFs, the dbg Tracer, and Match Specifications

Any respectable programming language that has deployments consisting of millions of lines of code running in thousands of installations worldwide must provide built-in low-level tracing mechanisms on which to build tools that can be used for live troubleshooting. Languages that don’t provide these tools put a huge burden on developers and support engineers alike, as they have to either develop this infrastructure from scratch themselves or troubleshoot their systems in a black-box environment.

In Erlang, Ericsson’s experiences of tracing live telephony switches are reflected in the trace BIFs, which, from being part of the first version of the language, have evolved through the years to become the foundation for a set of tools that give full visibility to the changing state of the system and, as a result, drastically reduce bug resolution times and troubleshooting efforts.

Introduction

Imagine you receive a bug report from a live system, where you get a badmatch error when pattern matching the result of the call ets:lookup(msgQ, MsgId). You expect your program to pattern-match on an atom denoting a message type, but instead it terminates when coming across the tuple {error, unknown_msg}.

You can quickly establish that the database got corrupted and set about trying to find the ets:insert/2 call that wrote the entry into the ETS table. As messages entering the system are tested at the system boundary, this message should ...