Bug #8866 Test 'kill' fails in PS protocol: Server crash on 'select get_lock("a", 10)'
Submitted: 1 Mar 2005 15:13 Modified: 27 Apr 2005 1:55
Reporter: Joerg Bruehe Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:5.0.3-pre OS:Other (Irix + Mac OS X)
Assigned to: Jim Winstead CPU Architecture:Any

[1 Mar 2005 15:13] Joerg Bruehe
Description:
Build based on changeset
  1.1774 05/03/01 01:59:37 petr@mysql.com +1 -0
  Merge pchardin@bk-internal.mysql.com:/home/bk/mysql-5.0
  into mysql.com:/home/cps/mysql/devel/im-fix-review

Test 'kill' passes in default test run, but fails when run with '--ps-protocol'. Message:

kill                           [ fail ]

Errors are (from /usr/people/mysqldev/octane2/test/mysql-standard-5.0.3-alpha-sgi-irix6.5-mips/mysql-test/var/log/mysqltest-time) :
/usr/people/mysqldev/octane2/test/mysql-standard-5.0.3-alpha-sgi-irix6.5-mips/bin/mysqltest: At line 43: unable to execute statement 'select get_lock("a", 10)': Lost connection to MySQL server during query (mysql_stmt_errno=2013 returned=1)
(the last lines may be the most important ones)

Ending Tests
Shutting-down MySQL daemon

Master shutdown finished
Slave shutdown finished
limit                          [ pass ]

This happens on 'octane2', 'powermacg4', and 'powermacg5' with identical message.
Tree is saved on 'octane2' as '~/bug####' (renamed to this bug# when it is known).

How to repeat:
Build + test on any of these.
[17 Mar 2005 1:13] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/23122
[17 Mar 2005 19:17] Jim Winstead
Fix pushed to 5.0.3 build tree.
[18 Mar 2005 18:00] Joerg Bruehe
Still happening on IRIX (32 + 64) and both Mac OS X versions, but only in a test run with '--ps-protocol'.
[21 Mar 2005 10:33] Joerg Bruehe
Next 5.0.3 release attempt, based on ChangeSet
  1.1837 05/03/20 14:38:51 joerg@mysql.com +1 -0
  Import Heikki's patch which was applied to the main tree only.

Includes also ChangeSet
  1.1835 05/03/18 16:17:10 jimw@mysql.com +2 -0
  Fix 'kill' test to actually test that the connection has
  been killed.

with this patch to 'mysql-test/t/kill.test':
@@ -27,8 +27,9 @@
 monty   1.2   | --sleep 5
 monty   1.2   | # verify that con1 is doning a reconnect
 sasha   1.1   | connection con1;
-monty   1.2   | ping
-monty   1.2   | ping
+jimw    1.10  | --ping
+jimw    1.10  | --ping
+jimw    1.10  | select ((@id := kill_id) - kill_id) from t1; 
 monty   1.2   | select @id != connection_id();
 sasha   1.1   | 
 sasha   1.1   | #make sure the server is still alive

Has moved the error to an earlier occurrence, now here:

kill                           [ fail ]

Errors are (from /Users/mysqldev/powermacg4/test/mysql-debug-5.0.3-alpha-apple-darwin6.8-powerpc/mysql-test/var/log/mysqltest-time) :
/Users/mysqldev/powermacg4/test/mysql-debug-5.0.3-alpha-apple-darwin6.8-powerpc/bin/mysqltest: At line 32: unable to execute statement 'select ((@id := kill_id) - kill_id) from t1': Lost connection to MySQL server during query (mysql_stmt_errno=2013 returned=1)
(the last lines may be the most important ones)

So now it is in line 32, formerly it was line 43. 
Still only in "--ps-protocol" tests.
Only two platforms now: Irix (64 bit, "octane2") + Max OS X 10.2 (6.8, "g4"),
it now passes on Mac OS X 10.3 (7.8, "g5").
[26 Mar 2005 3:50] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/23385
[28 Mar 2005 18:00] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/23414
[5 Apr 2005 20:07] Jim Winstead
Fixed in 4.1.12 and 5.0.4.

This means that when MYSQL->reconnect is set, the reconnect will happen with prepared statements as well as regular queries. But when the connection is reset, statements that were in-process will be disconnected. (Sorry, I don't know the prepared statement API well enough to explain this clearly.)
[27 Apr 2005 1:55] Paul DuBois
Noted in 4.1.12, 5.0.4 changelogs.