Differences Between Standard GDB and Teradata C/C++ UDF Debugger Commands - Analytics Database - Teradata Vantage

SQL External Routine Programming

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
VMware
Product
Analytics Database
Teradata Vantage
Release Number
17.20
Published
June 2022
Language
English (United States)
Last Update
2023-07-11
dita:mapPath
iiv1628111441820.ditamap
dita:ditavalPath
qkf1628213546010.ditaval
dita:id
B035-1147
lifecycle
latest
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.