From sigrok
Jump to: navigation, search

This page contains documentation and resources for aspiring sigrok developers.

Source code browser

Tutorials and API descriptions

Development guidelines

Please check the respective sub-project's HACKING file for coding guidelines and development tips.

Design pages

This is a list of pages we use while working through new features or designs. They are working documents, not official API or feature documentation.

Debugging (runtime messages)

If you would like to see the output of the sr_dbg() or sr_err() functions you can use one of the following sigrok-cli options:

$ export SIGROK_DEBUG=1


$ sigrok-cli -l 5 <options> 

The 5 above is the log level. The following levels are available:

  • 0: no output at all
  • 1: error messages
  • 2: warnings (the default)
  • 3: informational messages
  • 4: debug
  • 5: spew

Debugging (debug symbols)

If you want to enable debug information in compiler output, to receive fault information with symbolic information, or run the software under a debugger's control, setup e.g. CFLAGS=-g before running ./configure or adjust the CMAKE_BUILD_TYPE to Debug or RelWithDebInfo.

See the valgrind section below for more detailled examples.

Temporarily build PulseView with clang


PulseView and GDB

PulseView can be a bit tricky to debug as running it in GDB can stall the entire X11 session when PulseView crashes. This can be worked around, however. One approach is running GDB with a script that automatically creates a backtrace and terminates GDB (and thus, PulseView):

$ gdb --command=auto_bt.gdb build/bin/pulseview

with auto_bt.gdb containing lines as these:

run -l 5
thread apply all bt

Another approach is to run gdb in tmux. When X11 freezes you can switch to a different virtual console, reattach to tmux, and continue the debugging process from there. This approach also makes it easier to use breakpoints.


The following instructions outline how you can use valgrind to help find memory-related bugs in the sigrok libraries and frontends.

Debug packages setup (optional):

In order to get more useful output from valgrind you can (optionally) install various -dbg packages (if your distro provides them).

Example for libsigrok / libsigrokdecode / sigrok-cli on Debian:

$ apt-get install libgcc1-dbg libpcre3-dbg libglib2.0-0-dbg libftdi1-dbg zlib1g-dbg libasound2-dbg python3-dbg valgrind-dbg

For Qt and/or Boost based frontends (e.g. PulseView) additional packages might be helpful in some cases:

$ apt-get install libboost1.50-dbg libqt4-dbg libstdc++6-4.7-dbg libaudiofile-dbg \
  libsm6-dbg libice6-dbg libxt6-dbg libicu48-dbg libjpeg62-dbg


Here's a short overview of how to build the sigrok subprojects for use with valgrind. Basically everything should be built with -g O0 (enable debug output, and disable compiler optimizations). In this example, everything is installed into a custom install directory ($HOME/sr) in order to have a clean and consistent environment.

$ cd libsigrok; CFLAGS="-g -O0" ./configure --prefix=$HOME/sr && make install
$ cd libsigrokdecode; CFLAGS="-g -O0" ./configure --prefix=$HOME/sr && make install
$ cd sigrok-cli; CFLAGS="-g -O0" PKG_CONFIG_PATH=$HOME/sr/lib/pkgconfig ./configure --prefix=$HOME/sr && make install
$ cd pulseview; CXXFLAGS="-g -O0" PKG_CONFIG_PATH=$HOME/sr/lib/pkgconfig cmake . -DCMAKE_INSTALL_PREFIX:string=$HOME/sr && make install


You can now run valgrind with your preferred options against the tools/libs in $HOME/sr. Note that G_SLICE=always-malloc G_DEBUG=gc-friendly should be used to get valgrind-friendly glib behaviour.

Different command-line options, attached hardware and so on, will test different code paths in the libs/tools (e.g. sigrok-cli), of course.

$ LD_LIBRARY_PATH=$HOME/sr/lib G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full \
  --num-callers=40 --track-origins=yes --leak-resolution=high --track-fds=yes --fullpath-after=. \
  --read-var-info=yes ~/sr/bin/sigrok-cli --help

Release process

See Release process.