IBM Streams 4.3.0

Debugging source code using gdb

When a breakpoint is stopped for an input port, you can use the (g)db command to have the Streams Debugger provide some commands for inspecting the application elements that can be observed while debugging. Start the gdb source code debugger for the operator process method.

Use this method for debugging user written source code. The parameter to the (g)db command is the probe point ID of the currently stopped breakpoint. This example command opens gdb in a new window.

(sdb) gdb 0
Wrote GDB commands to file ./data/Writer.i.0.gdb
(sdb)

The last two lines in this example, show the breakpoint set for the process methods in the operator (one for tuple handling and another for punctuation handling).

Loaded symbols for /lib64/libkeyutils.so.1
Reading symbols from /user/lin64/libicudata.so.36...done.
Loaded symbols for /usr/lib64/libicudata.so.36
Reading symbols from /lib64/libselinux.so.1...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /lib64/libsepol.so.1...done.
Loaded symbols for /lib/libsepol.so.1
0x00000031fea07655 in pthread join () from /lib64/libpthread.so.0
Breakpoint 1 at 0x4185d0: file ../operator/Writer.cpp, line 34.
Breakpoint 2 at 0x418640: file ../operator/Writer.cpp, line 19.

When you run the (c)ontinue command in the sdb, the execution is resumed and the gdb breakpoint suspends the program.

(sdb) c 0
(sdb)

Note: When gdb is in control of debugging the source code, the sdb becomes blocked and cannot respond to command-line input until you continue execution from gdb. Using gdb in combination with sdb becomes an interplay of two debuggers where only one of the debuggers is in control at any one time.