Differences Between Standard GDB and Teradata C/C++ UDF Debugger Commands - Advanced SQL Engine - Teradata Database

SQL External Routine Programming

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
17.00
Published
June 2020
Language
English (United States)
Last Update
2021-01-24
dita:mapPath
qwr1571437338192.ditamap
dita:ditavalPath
lze1555437562152.ditaval
dita:id
B035-1147
lifecycle
previous
Product Category
Teradata Vantage™

The Teradata C/C++ UDF Debugger extends GDB; therefore all GDB commands that are available for normal debugging are also available for debugging UDFs. Keep in mind that some operations are not safe (or possible) in a massively parallel environment, such as reverse execution and catching certain system calls (such as fork and exec).

When you use the Teradata C/C++ UDF Debugger, all threads attached to the debugger stop when any thread encounters a condition that stops it. The continue command runs all threads (unless they are held); the step and next commands only run the current thread. In contrast, some versions of GDB stop only the threads that encounter a breakpoint (or other condition that will stop them) and all other threads continue to run.

kill

The kill command aborts the current database request when issued in a UDF debugging session, not the attached process as in a normal GDB session. If more than one database session is joined to a debugging session, the kill command ends debugging of any active SQL requests from all joined sessions, but only the request for the current UDF is aborted. Database sessions can then restart queries to continue debugging their UDFs.

info thread

The info thread command lists all threads currently known to GDB. When debugging UDFs, it shows each thread selector in the Target Id field and the thread’s current instruction address. This can be useful to identify other UDFs that are running when one stops at a breakpoint.