Notes on debugging Plash
--log option to pola-run: this logs method calls received by the FsOp object. --log-file redirects this output to a file.
Setting the environment variable PLASH_LIBC_DEBUG=1 causes PlashGlibc to output some debugging information to stderr.
strace
strace on client process
- eg. pola-run ... -e strace PROG ARGS...
- strace does not follow across the setuid wrappers, so doing "strace -f" is not helpful. Can get around that by not using the setuid wrappers, although that might cause the problem to go away, because the environment would be different.
- You can run strace inside sandbox as well, provided there isn't a problem that prevents strace from starting.
strace and --log can be combined. The output has a tendency to overlap. Output from --log can occur in the middle of a line from strace. This could be fixed by adapting strace to use a common logging framework.
The logs produced by strace and --log are unwieldy. A tool for browsing and filtering logs would be very useful.
gdb
gdb on ServerProcess
- This is awkward in cases where the server process forks, but it is possible to attach gdb after a fork.
gdb on client program to debug PlashGlibc
- It is possible to run gdb inside a sandbox. The same caveat for running strace inside a sandbox applies.
Build PlashGlibc with debugging: add "-g" to the arguments in the CC parameter passed to configure, and remove any "-g1" argument. Debugging is disabled by default to save disc space and reduce the build time.
Automated tests
The automated tests (see TestingPlash) currently use the Python unittest framework. This framework makes it awkward to customise tests, output and collect debugging information, or run an interactive debugger when an error occurs. Consider changing the test framework.