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
To Next Page
Loading...