Bug #29611 count_distinct3,subselect,func_group fails on 64-bit platforms
Submitted: 7 Jul 2007 10:35 Modified: 11 Jul 2007 10:25
Reporter: Daniel Fischer Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:5.1 BK OS:Any
Assigned to: Assigned Account CPU Architecture:Any

[7 Jul 2007 10:35] Daniel Fischer
Description:
Test case count_distinc3 fails on HP/UX 11.00,11.11,11.23, OS X Tiger PPC, Solaris Sparc, AIX 5.2, all 64-bit only:

count_distinct3                [ fail ]

Errors are (from /PATH/mysqltest-time) :
mysqltest: At line NNN: query 'SELECT COUNT(DISTINCT id) FROM t1 GROUP BY grp' failed: 2013: Lost connection to MySQL server during query
(the last lines may be the most important ones)
Result from queries before failure can be found in /PATH/mysql-test/var/log/count_distinct3.log

And in embedded:

count_distinct3                [ fail ]

ERROR: mysqltest returned unexpected code 139, it has probably crashed

Or:

count_distinct3                [ fail ]

ERROR: mysqltest returned unexpected code 138, it has probably crashed

How to repeat:
Run test case on affected platforms with 5.1.20 binaries.
[7 Jul 2007 10:39] Daniel Fischer
Test cases subselect and func_group fail with same symptomps.
[7 Jul 2007 10:50] Daniel Fischer
And also ctype_tis620, ctype_ujis_ucs2, multi_update, order_fill_sortbuf, rpl_optimize.
[7 Jul 2007 14:37] Sveta Smirnova
Thank you for the report.

Verified as described.
[11 Jul 2007 10:25] Evgeny Potemkin
Duplicate of the bug#29610.
[23 Jul 2007 16:46] 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/commits/31395

ChangeSet@1.2482, 2007-07-22 18:26:16-07:00, igor@olga.mysql.com +3 -0
  Fixed bug #29611.
  If a primary key is defined over column c of enum type then 
  the EXPLAIN command for a look-up query of the form
    SELECT * FROM t WHERE c=0
  said that the query was with an impossible where condition though the
  query correctly returned non-empty result set when the table indeed 
  contained rows with error empty strings for column c. 
  
  This kind of misbehavior was due to a bug in the function 
  Field_enum::store(longlong,bool) that erroneously returned 1 if
  the the value to be stored was equal to 0. 
  Note that the method 
  Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
  correctly returned 0 if a value of the error empty string 
  was stored.
[26 Jul 2007 5:55] Bugs System
Pushed into 5.1.21-beta
[26 Jul 2007 5:56] Bugs System
Pushed into 5.0.48