Bug #59504 Assert in Protocol::end_statement() for LOAD DATA
Submitted: 14 Jan 2011 14:07 Modified: 22 Feb 2011 14:36
Reporter: Jon Olav Hauglid Email Updates:
Status: Can't repeat Impact on me:
Category:MySQL Server: DML Severity:S3 (Non-critical)
Version:trunk OS:Any
Assigned to: Jon Olav Hauglid CPU Architecture:Any

[14 Jan 2011 14:07] Jon Olav Hauglid
Found during RQG testing using WL5004 grammar.

Stack trace:
#6  0x00007f52517e7a71 in __assert_fail (assertion=0xcbcd7d "0", file=<value optimized out>, 
    line=522, function=0xcbd860 "void Protocol::end_statement()") at assert.c:81
#7  0x0000000000561524 in Protocol::end_statement (this=0x3c7ef58)
    at /export/home/x/mysql-trunk-rqg2/sql/protocol.cc:522
#8  0x00000000005e23f5 in dispatch_command (command=COM_QUERY, thd=0x3c7ea30, 
    packet=0x3c81b31 " LOAD DATA  INFILE '/tmp/gentest9631.tmp'  INTO TABLE testdb_S . t1_base1_N ", packet_length=76) at /export/home/x/mysql-trunk-rqg2/sql/sql_parse.cc:1438

(gdb) p thd->stmt_da->m_status
$4 = Diagnostics_area::DA_EMPTY

Only seen once so far, so probably low likelihood of hitting this bug.

How to repeat:
Run RQG with WL5004 grammar and wait.

Suggested fix:
Fix LOAD DATA so it always calls my_ok() or my_error().
[22 Feb 2011 14:36] Jon Olav Hauglid
I've not hit this bug for the last two weeks, even when running RQG
continuously. Before I hit the bug roughly every other day. There have been
several changes to related code since then, but it's hard to say what caused
the bug to disappear since I've never been able to reproduce it reliably.

Closing the bug as "Can't repeat". If I see the problem again, I'll
reopen the bug.