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.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.058 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.