{"id":2895,"date":"2019-09-29T18:07:03","date_gmt":"2019-09-29T18:07:03","guid":{"rendered":"https:\/\/nenadnoveljic.com\/blog\/?p=2895"},"modified":"2019-09-29T18:07:05","modified_gmt":"2019-09-29T18:07:05","slug":"enriching-trace-with-call-stacks-gdb","status":"publish","type":"post","link":"https:\/\/nenadnoveljic.com\/blog\/enriching-trace-with-call-stacks-gdb\/","title":{"rendered":"Enriching Trace with Call Stacks Part 2: gdb"},"content":{"rendered":"

In a previous blog post<\/a> I explained how to gather call stacks with DTrace every time a string of interest gets written into a trace file. This technique comes in handy when researching propriatery software internals. I’ve been using it often to study optimizer; among others, to identify Oracle C functions participating in various query transformations. Unfortunately, DTrace isn’t always available, so I came up with an alternative approach based on gdb.<\/p>\n

Also here, I use the same tactic – printing the output buffer and backtrace in the intercepted OS kernel function write calls.<\/p>\n

Almost always, there will be plenty of write calls, so we have to be very selective about when to stop and capture the information. The write function specification helps us narrowing down the focus:<\/p>\n

NAME\n       write, pwrite, writev - write on a file\n\nSYNOPSIS\n       ssize_t write(int fildes<\/span>, const void *buf<\/span>, size_t nbyte);\n...\nDESCRIPTION\n       The  write()  function  attempts  to  write nbyte bytes from the buffer\n       pointed to by buf, to the file associated with the open  file  descrip-\n       tor, fildes.\n...\n;<\/code><\/pre>\n
The first argument is the file descriptor. It can be retrieved for the traced process with the pfiles utility:<\/p>\n
pfiles PID\n...\n  15<\/span>: S_IFREG mode:0640 dev:275,65861 ino:3334935 uid:1000 gid:1000 size:112333 (110KB)\n      O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC\n      \/u00\/oracle\/orabase\/diag\/rdbms\/db_site1\/DB\/trace\/DB_ora_16204.trc\n      offset:112333 (110KB)\n...<\/code><\/pre>\n
As you can see, the file descriptor for the dedicated server process’ trace file is 15<\/span>. (I switched the optimizer tracing on prior to executing pfiles.) The second argument is the buffer address which contains string to be written. Since the first two arguments are passed via the CPU registers rdi<\/span> and rsi<\/span>, we can set a conditional breakpoint as follows:<\/p>\n
b *write if $rdi == 15<\/span> && strstr($rsi,\"JPPD\"<\/span>)<\/code><\/pre>\n
The program execution will stop when the string JPPD<\/span> (Join Predicate Push-Down) is to be written into the trace file.<\/p>\n
The following breakpoint commands print out the buffer content and call stack before continuing with the further execution.<\/p>\n
commands 1\nsilent\nx\/s $rsi<\/span>\nbt\ncontinue\nend<\/code><\/pre>\n
Also, I usually configure resuming on received signal (unwindonsignal on), logging to file as well as disable the interactive mode (pagination off).<\/p>\n
attach PID\n\nset unwindonsignal on\n\nset pagination off\n\nset logging file stacks5.log\nset logging on\n\nc\n\nset logging off<\/code><\/pre>\n
Find below an example of a stack captured during a JPPD transformation:<\/p>\n
0x7fffbfff1990: \"JPPD<\/span>:   Checking validity of push-down from query block MAIN (#1) to query block RECEIVER (#2)\\n\"\n#0  0x00007ffc3083d0c0 in write () from \/lib\/64\/libc.so.1\n#1  0x000000000b181d82 in sdbgrfuwf_write_file ()\n#2  0x000000000b181cea in sdbgrfwf_write_file ()\n#3  0x000000000b165ae0 in dbgtfdFileWrite ()\n#4  0x000000000b0d1527 in dbgtfdFileAccessCbk ()\n#5  0x000000000b163365 in dbgtfWriteRec ()\n#6  0x000000001d6a375a in dbgtRecVAWriteDisk ()\n#7  0x000000001d699e52 in dbgtGrpBVaList_int ()\n#8  0x000000000b37ef1d in dbgtGrpB_int ()\n#9  0x0000000019a38fb1 in kkqjpdcvvpd<\/span> ()\n#10 0x000000000a775125 in kkqjpdctr<\/span> ()\n#11 0x000000000a47ba33 in qksqbApplyToQbcLoc ()\n#12 0x000000000a47b6e4 in qksqbApplyToQbc ()\n#13 0x000000000a478d82 in kkqctdrvTD ()\n#14 0x000000000a774544 in kkqjpddrv<\/span> ()\n#15 0x000000000a471250 in kkqdrv ()\n#16 0x000000000a46e6a0 in kkqctdrvIT ()\n#17 0x000000000a25e5bb in apadrv ()\n#18 0x000000000a2583fa in opitca ()\n#19 0x000000000a25796c in kksFullTypeCheck ()\n#20 0x0000000009d2fbdc in rpiswu2 ()\n#21 0x000000000a469bc6 in kksLoadChild ()\n#22 0x000000000a24c25d in kxsGetRuntimeLock ()\n#23 0x000000000a240ad0 in kksfbc ()\n#24 0x000000000a463ee0 in kkspsc0 ()\n#25 0x000000000a2ddd17 in kksParseCursor ()\n#26 0x000000000a2d9876 in opiosq0 ()\n#27 0x000000000a4636d7 in kpooprx ()\n#28 0x000000000a393c25 in kpoal8 ()\n#29 0x0000000009d08cee in opiodr ()\n#30 0x0000000009d120d2 in ttcpip ()\n#31 0x0000000009d0e318 in opitsk ()\n#32 0x0000000009d0cf64 in opiino ()\n#33 0x0000000009d08cee in opiodr ()\n#34 0x0000000009d082b2 in opidrv ()\n#35 0x0000000009d07f07 in sou2o ()\n#36 0x0000000009d07d4e in opimai_real ()\n#37 0x0000000009d07866 in ssthrdmain ()\n#38 0x0000000009d075d7 in main ()<\/code><\/pre>\n
If you’d like to gather call stacks related to, for instance, the OR-Expansion (ORE<\/span>), you can just change the breakpoint condition:<\/p>\n
cond 1 $rdi == 15 && strstr($rsi,\"ORE:\"<\/span>)<\/code><\/pre>\n
Here’s an example of a captured call stack:<\/p>\n
0x7fffbfff4c00: \"ORE<\/span>: after OR Expansion:******* UNPARSED QUERY IS *******\\n\"\n#0  0x00007ffc3083d0c0 in write () from \/lib\/64\/libc.so.1\n#1  0x000000000b181d82 in sdbgrfuwf_write_file ()\n#2  0x000000000b181cea in sdbgrfwf_write_file ()\n#3  0x000000000b165ae0 in dbgtfdFileWrite ()\n#4  0x000000000b0d1527 in dbgtfdFileAccessCbk ()\n#5  0x000000000b188891 in dbgtfPutStr ()\n#6  0x000000000b18806d in dbktPri ()\n#7  0x000000000b2125e3 in ksdwrf ()\n#8  0x000000001562296d in msqPrintQuery ()\n#9  0x0000000010d4d986 in qksqbDumpAsSQL ()\n#10 0x0000000019b48fb3 in kkqoreBuildUA<\/span> ()\n#11 0x0000000019b48231 in kkqoreTransform<\/span> ()\n#12 0x0000000019b40fbf in kkqoregdtr<\/span> ()\n#13 0x000000000a47ba33 in qksqbApplyToQbcLoc ()\n#14 0x000000000a47b6e4 in qksqbApplyToQbc ()\n#15 0x0000000019b40ecf in kkqoredrv<\/span> ()\n#16 0x000000000a470232 in kkqdrv ()\n#17 0x000000000a46e6a0 in kkqctdrvIT ()\n#18 0x000000000a25e5bb in apadrv ()\n#19 0x000000000a2583fa in opitca ()\n#20 0x000000000a46907b in kksLoadChild ()\n#21 0x000000000a24c25d in kxsGetRuntimeLock ()\n#22 0x000000000a240ad0 in kksfbc ()\n#23 0x000000000a463ee0 in kkspsc0 ()\n#24 0x000000000a2ddd17 in kksParseCursor ()\n#25 0x000000000a2d9876 in opiosq0 ()\n#26 0x000000000a4636d7 in kpooprx ()\n#27 0x000000000a393c25 in kpoal8 ()\n#28 0x0000000009d08cee in opiodr ()\n#29 0x0000000009d120d2 in ttcpip ()\n#30 0x0000000009d0e318 in opitsk ()\n#31 0x0000000009d0cf64 in opiino ()\n#32 0x0000000009d08cee in opiodr ()\n#33 0x0000000009d082b2 in opidrv ()\n#34 0x0000000009d07f07 in sou2o ()\n#35 0x0000000009d07d4e in opimai_real ()\n#36 0x0000000009d07866 in ssthrdmain ()\n#37 0x0000000009d075d7 in main ()<\/code><\/pre>\n
Last but not least, a traced process normally executes many write calls. As a consequence, breakpoint handling will inevitably introduce an enormous overhead. For example, a 10053-traced optimization taking 5s to complete lasted almost 1.5 minutes after setting a breakpoint on write. Therefore, use this technique prudently – that is, only for experimenting on your sandbox databases. Interestingely, tracing with DTrace is much lighter – the same optimization lasted “only” 12s.<\/p>\n
By the way, below are the links to case studies where I used gdb for researching Oracle database internals:<\/p>\n