68 lines
3.2 KiB
Plaintext
68 lines
3.2 KiB
Plaintext
[[debugging]]
|
|
== Debugging
|
|
|
|
{app-name} is a complex program which at the same time orchestrates sets of
|
|
other complex programs to form a network of nodes. As such, it can be sometimes
|
|
challenging to find out what is going on during a trial run. This section aims
|
|
at providing some tips on how to debug possible issues.
|
|
|
|
=== Logging level
|
|
|
|
{app-name} runs by default under 'info' log level. As a first debugging step, it
|
|
is always a good idea to increase log verbosity. By switching to debug level
|
|
(command line argument '-l dbg'), a lot more information and events are displayed which
|
|
can give a much better idea to understand possible misconfigurations or wrong
|
|
steps.
|
|
|
|
In any case, {app-name} usually provides several log files of interest. In
|
|
general, both a 'log' and a 'log_brief' are stored directly under the trial's
|
|
run directory, the first containing output up to debug level included, while the
|
|
second contains output up to info level included. Furthermore, {app-name} writes
|
|
a debug level log file per test case under each test's run directory.
|
|
|
|
It is also in general useful to enable the '-T' command line argument. By using
|
|
it, it will instruct {app-name} to write the full backtrace to the log output
|
|
when something wrong happens, such an unexpected exception.
|
|
|
|
[[pdb]]
|
|
=== python debugger
|
|
|
|
{app-name} can be further debugged using python's debugger 'pdb'. Easiest way to
|
|
use it is to modify the python code were you want to break and add this code:
|
|
----
|
|
import pdb; pdb.set_trace()
|
|
----
|
|
|
|
When {app-name} runs over that code, it will pause and provide a debugging
|
|
interactive shell, where one can inspect variables, execute code, etc.
|
|
|
|
TIP: Remember {app-name} is managed by its internal main loop, meaning if you
|
|
jump into a debugger console you will still need to give back control to the
|
|
main loop for events to be processed and checks done. That can be done for
|
|
instance by calling the 'MainLoop.sleep(log_obj, secs)' internal API in general
|
|
or `sleep(secs)' under test context.
|
|
|
|
=== debug suite
|
|
|
|
Sometimes, however, one may be interested in debugging the behavior of the
|
|
software under test by {app-name} rather than {app-name} itself. For instance,
|
|
one may simply want to set up a full running network of nodes and keep it up
|
|
until some manual tests are done, or one may want {app-name} to do so at a given
|
|
point of time.
|
|
|
|
To fulfill this kind of scenarios, {app-name} provides some code available for
|
|
tests to gain access to a high-level interactive console which is fully
|
|
integrated with {app-name}'s own main loop. So the approach here is usually to
|
|
write a regular test (with its corresponding <<suite_conf,suite.conf>>) to set
|
|
up and run all required processes and then allow it to jump into the interactive
|
|
console instance. Then the test pulls received commands from it and it is
|
|
responsible for parsing and implementing them. One command can for instance ask
|
|
a modem to send an sms to another. Another command can for instance jump into a
|
|
<<pdb,debugger console>>.
|
|
|
|
The interactive console is available to tests through the 'prompt' method, and
|
|
its implementation can be found under 'method input_polling' in 'util.py'.
|
|
|
|
An interactive console example as explained in this section can be found under
|
|
the 'debug/interactive.py' test in osmo-gsm-tester.git.
|