Bug #36151 Proxy parser.lua -- get_tables function works unexpectedly on subsequent uses
Submitted: 16 Apr 2008 19:18
Reporter: Lachlan Mulcahy Email Updates:
Status: Verified Impact on me:
Category:MySQL Proxy: Scripts Severity:S3 (Non-critical)
Version:0.6.1, 0.7.1 OS:Any
Assigned to: Assigned Account CPU Architecture:Any
Tags: Contribution
Triage: D2 (Serious) / R1 (None/Negligible) / E1 (None/Negligible)

[16 Apr 2008 19:18] Lachlan Mulcahy
When using the get_tables function on the parser.lua script bundled with proxy, running the parser more than once gives incorrect/unexpected results.

How to repeat:
Create bugtest.lua:

function read_query ( packet ) 

            local query = "DROP TABLE t"

            local tk = require('proxy.tokenizer')
            local pr = require('proxy.parser')
            local tokens = tk.tokenize(query)

            local tbls = pr.get_tables(tokens)

            for k, v in pairs(tbls) do
                print(k.." => "..v)

            tbls = pr.get_tables(tokens)

            for k, v in pairs(tbls) do
                print(k.." => "..v)

            return proxy.PROXY_SEND_QUERY


shell> mysql-proxy --proxy-lua-script=bugtest.lua

Connect to the proxy, issue some query and watch the output.

Suggested fix:
Initialise the ddl_type variable in the get_tables function to avoid subsequent executions using the old value...

Apply this diff to ./lib/proxy/parser.lua:

>     local ddl_type = nil
[3 Jun 2009 14:49] Kay Roepke
This problem seems to persist in version 0.7.1 and trunk, but I'm confused about the output.
Even with the patch there seems to be a problem, but I can't quite figure out what I'm missing off-hand.

Needs test case.
[11 Jan 2010 19:31] Kay Roepke
The branch https://code.launchpad.net/~roger-booth/mysql-proxy/laminator has a proposed fix contributed by Roger Booth.
Test case is in progress.
[12 Jan 2010 3:35] Roger Booth
Test the bug with aribtrary queries, without executing them

Attachment: bugtest2.lua (text/x-lua), 868 bytes.

[12 Jan 2010 3:44] Roger Booth
Using the second version of the test script, I ran these queries while connected to the proxy server via the 'test' database.

UPDATE content SET foo = 'n', id = '2944786' WHERE ( id = '2944786' );
SELECT id from db1.notes;
update db2.notes set message = 'Will it?' where section_id = 61465;
insert into db0.courses (name,instructor) values ('PHY200',1040752);

The DROP TABLE query only prints once, which seems to indicate the initial bug.  However other types of queries don't show this behavior.  There is an additional problem when a write query uses a table in the form 'db.table'.  Both the db and the table are identified as tables.

test.t => write
test.sessions => write
test.db1 => write
test.sessions => write
test.db1 => write
test.content => write
test.content => write
db1.notes => read
db1.notes => read
test.db2 => write
test.notes => write
test.db2 => write
test.notes => write
test.db0 => write
test.db0 => write
[7 May 2010 12:03] Enterprise Tools JIRA Robot
Diego Medina writes: 
It was assigned to me by mistake