{"id":1623,"date":"2017-11-13T19:40:28","date_gmt":"2017-11-13T19:40:28","guid":{"rendered":"http:\/\/nenadnoveljic.com\/blog\/?p=1623"},"modified":"2020-08-21T12:22:14","modified_gmt":"2020-08-21T12:22:14","slug":"memory-leak-parsing","status":"publish","type":"post","link":"https:\/\/nenadnoveljic.com\/blog\/memory-leak-parsing\/","title":{"rendered":"Memory Leak During Parsing"},"content":{"rendered":"

In this blog post I’ll be exploring the behaviour of the Oracle function qcplgte and describing edge conditions that could lead to a memory leak during query parsing. The analysis was conducted on a Oracle 12.2 database and Solaris 11.<\/p>\n

qcplgte<\/h1>\n

qcplgte is one of the auxiliary functions in Oracle database that underpin SQL parsing. In particular, this function divides the SQL text into several parts. In Oracle 12.2, the function receives a pointer through the second argument. The address to the next part of the SQL string to parse is stored at the 8 bytes offset. After parsing the portion of the SQL text, the function will update the same memory location with the pointer to the substring for the next parsing stage.<\/p>\n

The following picture shows how the function finds the SQL text to parse.<\/p>\n

\"qcplgte\"<\/a>

qcplgte<\/p><\/div>\n

After having figured out the input, it is fairly easy to come up with gdb commands which will display all of the parsing stages:<\/p>\n

break qcplgte\nset pagination off\ncommands 1\nsilent\nx\/s *(uint64_t *)($rsi+0x8)\ncontinue\nend<\/code><\/pre>\n
Here’s the short explanation of the commands above: According to x64 calling convention for System V<\/a> the second parameter is passed through the %rsi register. The pointer to the SQL text is stored in the memory location %rsi+8. The OS is 64-bit, therefore casting to uint64_t when dereferencing %rsi+0x8. Finally, x\/s will dereference the pointer to the (sub)string which is stored on the memory location %rsi+0x8.<\/p>\n
Let’s trace the following simple query by using the gdb script above:<\/p>\n
select a from t ;<\/code><\/pre>\n
where t is a very simple table created like this:<\/p>\n
create table t (a number) ;\nexec dbms_stats.gather_table_stats (USER,'T') ;<\/code><\/pre>\n
Note: Gathering statistics before running the query is important to avoid the noise which would be otherwise created by recursive dynamic sampling queries.<\/p>\n
The excerpt from the gdb output:<\/p>\n
0xffff80ffbfffb3c8:     \"select a from t\"\n0xffff80ffbfffb3ce:     \" a from t\"\n0xffff80ffbfffb3d0:     \" from t\"\n0xffff80ffbfffb3cf:     \"a from t\"<\/span>\n0xffff80ffbfffb3d0:     \" from t\"\n0xffff80ffbfffb3cf:     \"a from t\"<\/span>\n0xffff80ffbfffb3d0:     \" from t\"\n0xffff80ffbfffb3d5:     \" t\"\n0xffff80ffbfffb3d7:     \"\"\n0xffff80ffbfffb3d6:     \"t\"\n...<\/code><\/pre>\n
An interesting observation we can make by looking at the output above is that parsing is not linear. What I mean by that is the function had to examine some substrings, such as the one starting at the address 0xffff80ffbfffb3cf<\/span>, twice even for such a simple query.<\/p>\n
Footprint<\/h1>\n
Before making the initial query gradually more complex, we have to come up with a method for measuring the parsing footprint. For this reason, I wrote a DTrace script which collects the following information:<\/p>\n