Metview's documentation is now on readthedocs!


In order to debug Metview, you must first ensure that it has been built with debugging enabled:

Starting the debugger in the correct environment

When debugging a Metview module, the debugger must be started from the correct environment.

  • If you are running Metview from the directory where it was built (not installed), then you must start Metview with the command
    • metview -xserv
  • when you start Metview like this, you will see the XServ bar. There is a button here called debug which brings up an xterm with Metview's environment in it. Go to section "Debugging a module".
  • If you are running Metview from its installation directory, you can create a debug window as follows:
    1. Create a new Shell Script icon (from the New Icon desktop menu)
    2. Edit the icon and type 'xterm' (without the quotes) in it, and save
    3. Right-click | execute the Shell icon

Debugging a module

From a terminal which has the correct environment as described above, you can go to Metview's executable directory:


Now, you can either just start up your chosen module in this xterm to see more output messages from it, or else you can start the debugger with it. Generally, the command-line arguments -nofork and -debug should be supplied. In the case of the Macro module, -serve should also be supplied. Example with totalview:

tv8 ./ObsFilter -a -nofork -debug

If the module does not start, then it might be because it is already running - from a Metview desktop, choose Process Monitor from the Tools menu and stop the process. If debugging the Display Window, then the corresponding executable is called uPlot; running this will create an empty Display Window into which you can drop icons. Note that you may have to kill the existing instance of the module if it has already been run during this Metview session - use Metview's Process Monitor for this.

Example - getting more output from the Observation Filter:

 ./ObsFilter -nofork -debug

Now run your Observation Filter task and look at the output in the xterm.


  1. Just testing this now; -debug seems to have been changed to --debug.

    I also had to define the following environment variables, so static initialization could work, at least inside gdb (I've set them to $HOME to continue, but there's probably a more sensible choice):

    1. Hmmm... these should already be set inside the xterm that you get if you click the Debug button from the xserv bar

      1. Oh I see! I've completely bypassed it and I'm directly calling the module binary from the IDE (otherwise I don't have debugger integration). My fault!

  2. How do I pass arguments into a module when debugging (say to process user-defined options)?

  3. Not sure what you mean here - if you want to debug the module given a particular set of input parameters, then you edit the icon with the parameters you want, you start the module in the debugger (breakpoint on the serve(in, out) function), execute the icon, and the debugger will stop in the serve() function and the request is given as the 'in' parameter.

    If there are command-line parameters to be passed to the module, then it depends on the debugger. TotalView has a panel for entering command line args and env vars, or you can start the module with "tv8 bin/Regrid -a -nofork -other_arg1 -other_arg2". But in most cases, the command line arguments are handled by some central code, and not really 'seen' directly by the module itself.