Vaisala RVP900, User Manual, Page: 382 / 484

2. To debug
RVP9/Proc
code, in an X-Term window type:
$ rvp9 –noFork
which starts
RVP9/Main
threads, but pauses at the point that the
RVP9/Proc
process
would normally be created.
The
-noFork
forces the subprocess count to one, as if you had included
-procs 1
on
the original command line.
We do not want RVP9/Proc code to automatically start from the main threads.
When RVP9/Main is debugged in this way, signal events originating from ddd are
also sent to RVP9/Proc child threads. They are likely to cause them to behave
improperly.
Use this technique only for quick ventures into the main threads, and preferably with
-procs 0 .
3. In another terminal window:
a. To builds the new
RVP9/Proc
code and start the debugger, type:
$ cd /home/operator/src/rda/rvp9proc
$ make –j2
$ cd open
$ ddd rvp9proc
b. To start the subprocess, in in
ddd
, type;
run
When it has finished initializations
RVP9/Main
continues in the other window.
4. To debug
RVP9/Main
the complete way:
a. Run
ddd rvp9
as described above, but include the
-noFork
flag in the
ddd run
command.
b. Run
rvp9proc
manually in another window, either with or without its own
ddd
.
You can create two simultaneous Main and Proc ddd sessions in this manner. Signals
from one does not interfere with the other.
C.3.6 Finding Memory Leaks with
valgrind
The valgrind profiler is useful if you are having runtime problems that are hard to track
down.
RVP900 User Guide M211322EN-J
380