Debugging information
A buggy behaviour in a concurrent program can come from anywhere in the code. CauDEr collects state information and tries to show it in an understandable way in different parts of the interface.
The State tab shows the following information:
- The Global Mailbox (GM) state.
- Process states.
The GM is a device included to correctly model all the possible evaluation of concurrent programs. When a process sends a message, it is sent to the GM. The GM will (eventually) deliver this message to the corresponding process.
Note that, if we did not have a GM, then the messages should be copied directly to the mailbox of the receiving process (which is incorrect in a distributed environment). The GM appears in other works as the "ether", the "network", etc.
For each process, we show its header and its state.
The header is marked as:
=============== Proc. X ===============
where X is the Pid of that process.
The state is composed of:
- LM: The Local Mailbox of the process.
- H: The History of the process (the actions it has performed).
- ENV: The ENVironment of the process.
- EXP: The EXPression being evaluated by the process.
LM shows the messages in the mailbox of the process in a similar way to GM.
H shows the send, receive, and spawn items in reverse order (and self and seq items if full history is enabled).
ENV shows the environment (i.e., the mapping from variables to values) for the process.
EXP shows the current Core Erlang expression under evaluation.
The View options allow you to hide any component of the state of the process. These options also let the user choose
- Show only concurrent items (default) or all items in history.
- Show relevant bindings (the ones whose varaible appears in the expression) or full environment.
The Trace tab shows the concurrent events that have taken place in the system from global perspective.
These events are always shown in-order, in a linearized fashion. The concurrent nature of Erlang program may lead to Trace sequences that were not expected when writing the program.
When executing a rollback command, this rollback can be propagated to other dependent processes (i.e., the process that been sent a message or been spawned by the rollbacked process).
The Roll Log shows these rollback requests also in-order.