Home
Developing
Learn about different Teracloud Streams tools and features to write, compile, run, and test streams applications.
Debugging stream applications
Debug stream applications using the interactive, command line-based Streams Debugger (sdb).
Debugging with the Streams Debugger
When the application is started either in stand-alone mode or distributed mode, the Streams Debugger displays initial messages and presents a command line.
Debugging source code using gdb
When a breakpoint is stopped for an input port, you can use the gdb 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.

Welcome
Learn about the core capabilities of Teracloud® Streams, its architecture, and key concepts.
Installing
Use this information to install, upgrade, and uninstall the Teracloud® Streams product.
Configuring
Create a basic or an enterprise domain which is a single point for configuring and managing common resources, security, and instances.
Administering
Administer the product by using the Teracloud® Streams graphical user interface, APIs, or the streamtool command-line interface.
Developing
Learn about different Teracloud Streams tools and features to write, compile, run, and test streams applications.
- Development concepts
  Development of stream applications consists of several components such as operators, streams, tuples, Streams Processing Language, toolkits, and more.
- Developing stream applications
  Try out tutorials and explore details about stream application development, SPL features, and best practices.
- Developing native functions
  Extend SPL's computational capabilities by creating native functions written in C++ or Java.
- Developing custom operators
  Create custom operators if shipped toolkits do not provide the necessary logic or behavior needed for your stream applications.
- Developing custom toolkits
  Bundle and reuse custom functions and operators across several stream applications by creating custom toolkits.
- Working with files
  Applications and operators can read and write to files in several ways. If relative paths are used, the data directory is used as the root of relative paths. To enable logic to access the runtime application or toolkit directory hierarchies, language-specific functions can be used.
- Enabling Streams data exchange
  Teracloud® Streams provides a data exchange REST API for inserting and retrieving tuples within a job to easily integrate with other data services and external applications. Stream applications can enable the data exchange feature by using one or more Endpoint operators.
- Debugging stream applications
  Debug stream applications using the interactive, command line-based Streams Debugger (sdb).
  - Samples used for illustration
    The WordCount sample is used to illustrate the debugger features.
  - Compiling an application for debugging
    To compile a stream application for debugging with the Streams Debugger (sdb), you must specify the -g option on the sc command.
  - Debugging an application in stand-alone mode
    The SPL compiler generates a stand-alone executable program that can be run without a Teracloud® Streams instance.
  - Debugging an application in distributed mode
    A stream application is debugged in a job that is submitted to a running Teracloud® Streams instance.
  - Debugging with the Streams Debugger
    When the application is started either in stand-alone mode or distributed mode, the Streams Debugger displays initial messages and presents a command line.
    - Stream debugging based on operator ports
      The Streams Debugger provides a port-centric view into the stream application.
    - Probe points and probe point IDs
      Probe points include breakpoints, trace points, and inject points.
    - Suspending execution with breakpoints
      You set a breakpoint with the Streams Debugger to suspend execution of your application.
    - Continuing execution of a stopped breakpoint
      When you are stopped at a breakpoint, you continue execution with the (c)ontinue command.
    - Changing attribute values in tuples
      With the Streams Debugger you change values during a debugging session.
    - Dropping tuples from flow
      You can drop a tuple or punctuation from a port while debugging.
    - Tracing tuples with trace points
      You can trace the flow of tuples and punctuation through the ports of an operator.
    - Inserting tuples with inject points
      You can insert new tuples and punctuation into a port with an inject point.
    - Conditional probe points
      To make probe (break or trace) points conditional, you add an expression predicate to the probe point.
    - Debugging source code using gdb
      When a breakpoint is stopped for an input port, you can use the gdb 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.
    - Displaying operators, ports, and schema information
      The Streams Debugger provides some commands for inspecting the application elements that can be observed while debugging.
    - Searching for attributes
      The find command helps to locate attributes among all of the ports available in the debugger environment. You can search by attribute name, attribute type, or both with regular expression matching.
    - Saving probe point tuples to a file
      The save command can be used to save the tuple data for a breakpoint or trace point to a file for later use.
    - Saving and loading debug configuration
      The savecfg and loadcfg commands can be used to save your debug session and reload it during a subsequent debug session.
    - Setting console logging and tracing options
      You change the level and format for logging and tracing with the setdbg command.
    - Restrictions debugging an SPL program
      There are restrictions when you debug an SPL program with the Streams Debugger.
    - Streams debugger commands
      The Streams Debugger provides a set of commands to help you debug your application.
Troubleshooting
Resolve problems with Teracloud® Streams using the troubleshooting tools provided with the product as well as the resources offered by Teracloud Support.
Reference
Find details on the SPL language, toolkits, APIs, commands, and more.
Glossary
Use this glossary to find terms and definitions for Teracloud® Streams.

Debugging source code using gdb

When a breakpoint is stopped for an input port, you can use the gdb 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 gdb 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.