Bug #45261 Crash, stored procedure + decimal
Submitted: 2 Jun 2009 10:47 Modified: 12 Mar 2010 17:41
Reporter: Matthias Leich Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Stored Routines Severity:S3 (Non-critical)
Version:5.1,5.4 OS:Any
Assigned to: Georgi Kodinov CPU Architecture:Any
Triage: Triaged: D1 (Critical)

[2 Jun 2009 10:47] Matthias Leich
Description:
1. type_decimal executed with "cursor-protocol" crashes
   the server.
2. Experiments around lead to the following script:
--disable_warnings
DROP PROCEDURE IF EXISTS test_proc;
--enable_warnings
delimiter |;
CREATE PROCEDURE test_proc()
BEGIN
  # The las non critical CUSER definition is:
  # DECLARE mycursor CURSOR FOR SELECT 1 % .12345678912345678912345678912345678912345678912345678912345678912 AS my_col;
  DECLARE mycursor CURSOR FOR SELECT 1 % .123456789123456789123456789123456789123456789123456789123456789123456789123456789 AS my_col;
  OPEN mycursor;
  CLOSE mycursor;
END|
delimiter ;|
CALL test_proc();
DROP PROCEDURE test_proc;

Outcome in
mysql-bugteam-5.1, mysql-azalea May 2009
----------------------------------------
mysqltest: At line 14: query 'CALL test_proc()' failed: 2013: Lost connection to MySQL server during query

hread 1 (process 24065):
#0  0x00007f6405ac0ce6 in pthread_kill () from /lib64/libpthread.so.0
#1  0x0000000000b4d650 in my_write_core (sig=6) at stacktrace.c:309
#2  0x00000000006ec5cf in handle_segfault (sig=6) at mysqld.cc:2711
#3  <signal handler called>
#4  0x00007f64049bc5c5 in raise () from /lib64/libc.so.6
#5  0x00007f64049bdbb3 in abort () from /lib64/libc.so.6
#6  0x00007f64049b51e9 in __assert_fail () from /lib64/libc.so.6
#7  0x0000000000b272e6 in decimal_bin_size (precision=14, scale=30) at decimal.c:1445
#8  0x000000000063910d in my_decimal_get_binary_size (precision=14, scale=30) at ../../../../storage/ndb/include/kernel/signaldata/DictTabInfo.hpp:39
#9  0x00000000006b97a7 in Field_new_decimal (this=0x1646a90, len_arg=16, maybe_null_arg=true, name=0x163ab40 "my_col", dec_arg=30 '\036', unsigned_arg=false) at field.cc:2524
#10 0x000000000077dd8e in create_tmp_field_from_item (thd=0x16685b8, item=0x163aa58, table=0x16987a0, copy_func=0x41061470, modify_item=false, convert_blob_length=0) at sql_select.cc:13787
#11 0x000000000077e3c5 in create_tmp_field (thd=0x16685b8, table=0x16987a0, item=0x163aa58, type=Item::FUNC_ITEM, copy_func=0x41061470, from_field=0x1699408, default_field=0x16993f8, group=false, modify_item=false,
    table_cant_handle_bit_fields=false, make_copy_field=false, convert_blob_length=0) at sql_select.cc:13995
#12 0x000000000077f4e8 in create_tmp_table (thd=0x16685b8, param=0x1641d68, fields=@0x1639ed0, group=0x0, distinct=false, save_sum_fields=true, select_options=2147769856, rows_limit=18446744073709551615,
    table_alias=0xd5b6f3 "") at sql_select.cc:14336
#13 0x00000000008c2efd in select_union::create_result_table (this=0x1641d50, thd_arg=0x16685b8, column_types=0x1639ed0, is_union_distinct=false, options=2147769856, table_alias=0xd5b6f3 "", bit_fields_as_long=false)
    at sql_union.cc:129
#14 0x00000000008d3b17 in Select_materialize::send_result_set_metadata (this=0x1641d50, list=@0x1639ed0, flags=5) at sql_cursor.cc:720
#15 0x000000000079eced in JOIN::exec (this=0x16929e0) at sql_select.cc:2337
#16 0x000000000079b8ee in mysql_select (thd=0x16685b8, rref_pointer_array=0x1639fb0, tables=0x0, wild_num=0, fields=@0x1639ed0, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0,
    select_options=2147765760, result=0x1641d50, unit=0x1639960, select_lex=0x1639dc8) at sql_select.cc:3067
#17 0x00000000007a1149 in handle_select (thd=0x16685b8, lex=0x16398c0, result=0x1641d50, setup_tables_done_option=0) at sql_select.cc:310
#18 0x00000000006fc6e4 in execute_sqlcom_select (thd=0x16685b8, all_tables=0x0) at sql_parse.cc:4964
#19 0x00000000006fdf36 in mysql_execute_command (thd=0x16685b8) at sql_parse.cc:2172
#20 0x00000000008d4bf3 in mysql_open_cursor (thd=0x16685b8, flags=2, result=0x1604ca8, pcursor=0x1604cd8) at sql_cursor.cc:177
#21 0x00000000008e4d2b in sp_cursor::open (this=0x1604ca0, thd=0x16685b8) at sp_rcontext.cc:531
#22 0x00000000008db43e in sp_instr_copen::exec_core (this=0x163abe0, thd=0x16685b8, nextp=0x41063368) at sp_head.cc:3525
#23 0x00000000008dc0f3 in sp_lex_keeper::reset_lex_and_exec_core (this=0x163ab78, thd=0x16685b8, nextp=0x41063368, open_tables=false, instr=0x163abe0) at sp_head.cc:2753
#24 0x00000000008dc34c in sp_instr_copen::execute (this=0x163abe0, thd=0x16685b8, nextp=0x41063368) at sp_head.cc:3498
#25 0x00000000008de1ff in sp_head::execute (this=0x1638c80, thd=0x16685b8) at sp_head.cc:1249
#26 0x00000000008df023 in sp_head::execute_procedure (this=0x1638c80, thd=0x16685b8, args=0x166a898) at sp_head.cc:1990
#27 0x0000000000704a34 in mysql_execute_command (thd=0x16685b8) at sql_parse.cc:4422
#28 0x000000000070644b in mysql_parse (thd=0x16685b8, inBuf=0x1604090 "CALL test_proc()", length=16, found_semicolon=0x41064f30) at sql_parse.cc:5979
#29 0x0000000000707035 in dispatch_command (command=COM_QUERY, thd=0x16685b8, packet=0x16c9169 "CALL test_proc()", packet_length=16) at sql_parse.cc:1064
#30 0x00000000007084f9 in do_command (thd=0x16685b8) at sql_parse.cc:746
#31 0x00000000006f5c0d in handle_one_connection (arg=0x16685b8) at sql_connect.cc:1146
#32 0x00007f6405abc040 in start_thread () from /lib64/libpthread.so.0
#33 0x00007f6404a5d08d in clone () from /lib64/libc.so.6
#34 0x0000000000000000 in ?? ()

The server was compiled with "compile-pentium64-debug-max".
A server compiled with "compile-pentium64-max" shows the
same crash.

My envirionment:
Linux OpenSuSE 11.0 64 Bit, Intel Core2Duo
   

How to repeat:
Please use the commands above or the attached script.
[2 Jun 2009 10:58] Matthias Leich
test script

Attachment: ml013.test (application/octet-stream, text), 598 bytes.

[29 Jun 2009 8:22] 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/77424

2936 Martin Hansson	2009-06-29
      Bug#45261: Crash, stored procedure + decimal
      
      The truncation procedure for creating field for DECIMAL typed columns
      calculated overflow using a function that automatically truncated field
      length to avoid overflow, and this was caught much later than the actual
      error. 
      Fixed by creating a new function for field length calculation that does not
      truncate, and by adding and assertion in constructor for DECIMAL type
      column objects.
     @ mysql-test/r/type_newdecimal.result
        Bug#45261:
        
        - Wrong test result turned correct.
        - Test result.
     @ mysql-test/t/type_newdecimal.test
        Bug#45261: Test case.
     @ sql/field.cc
        Bug#45261: Added DBUG_ASSERT to ensure object's invariant is maintained.
     @ sql/field.h
        Bug#45261: Added comment to explain what member is for.
     @ sql/my_decimal.h
        Bug#45261: Created non-truncating overload of my_decimal_precision_to_length()
     @ sql/sql_select.cc
        Bug#45261: Fix: Using new non-truncating function.
[2 Jul 2009 12:17] 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/77765

2936 Martin Hansson	2009-07-02
      Bug#45261: Crash, stored procedure + decimal
      
      The truncation procedure for creating field for DECIMAL typed columns
      calculated overflow using a function that automatically truncated field
      length to avoid overflow, and this was caught much later than the actual
      error. 
      Fixed by creating a new function for field length calculation that does not
      truncate, and by adding an assertion in constructor for DECIMAL type
      column objects.
     @ mysql-test/r/type_newdecimal.result
        Bug#45261:
        
        - Wrong test result turned correct.
        - Test result.
     @ mysql-test/t/type_newdecimal.test
        Bug#45261: Test case.
     @ sql/field.cc
        Bug#45261: Added DBUG_ASSERT to ensure object's invariant is maintained.
     @ sql/field.h
        Bug#45261: Added comment to explain what member is for.
     @ sql/my_decimal.h
        Bug#45261: Created non-truncating version of my_decimal_precision_to_length()
     @ sql/sql_select.cc
        Bug#45261: Fix: Using new non-truncating function.
[2 Jul 2009 12:29] 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/77769

2936 Martin Hansson	2009-07-02
      Bug#45261: Crash, stored procedure + decimal
      
      The truncation procedure for creating field for DECIMAL typed columns
      calculated overflow using a function that automatically truncated field
      length to avoid overflow, and this was caught much later than the actual
      error. 
      Fixed by creating a new function for field length calculation that does not
      truncate, and by adding an assertion in constructor for DECIMAL type
      column objects.
     @ mysql-test/r/type_newdecimal.result
        Bug#45261:
        
        - Wrong test result turned correct.
        - Test result.
     @ mysql-test/t/type_newdecimal.test
        Bug#45261: Test case.
     @ sql/field.cc
        Bug#45261: Added DBUG_ASSERT to ensure object's invariant is maintained.
     @ sql/field.h
        Bug#45261: Added comment to explain what member is for.
     @ sql/my_decimal.h
        Bug#45261: Created non-truncating version of my_decimal_precision_to_length()
     @ sql/sql_select.cc
        Bug#45261: Fix: Using new non-truncating function.
[3 Jul 2009 12:05] 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/77894

2936 Martin Hansson	2009-07-03
      Bug#45261: Crash, stored procedure + decimal
      
      The truncation procedure for creating field for DECIMAL typed columns
      calculated overflow using a function that automatically truncated field
      length to avoid overflow, and this was caught much later than the actual
      error. 
      Fixed by taking into accunt the truncation during calculation, and by 
      adding an assertion in constructor for DECIMAL type column objects.
     @ mysql-test/r/type_newdecimal.result
        Bug#45261:
        
        - Wrong test result turned correct.
        - Test result.
     @ mysql-test/t/type_newdecimal.test
        Bug#45261: Test case.
     @ sql/field.cc
        Bug#45261: Added DBUG_ASSERT to ensure object's invariant is maintained.
     @ sql/field.h
        Bug#45261: Added comment to explain what member is for.
     @ sql/sql_select.cc
        Bug#45261: Fix: Using new non-truncating function.
[3 Jul 2009 14: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/77912

2936 Martin Hansson	2009-07-03
      Bug#45261: Crash, stored procedure + decimal
      
      The truncation procedure for creating field for DECIMAL typed columns
      calculated overflow using a function that automatically truncated field
      length to avoid overflow, and this was caught much later than the actual
      error. 
      Fixed by taking into accunt the truncation during calculation, and by 
      adding an assertion in constructor for DECIMAL type column objects.
     @ mysql-test/r/type_newdecimal.result
        Bug#45261:
        - Wrong test result turned correct.
        - Test result.
     @ mysql-test/t/type_newdecimal.test
        Bug#45261: Test case.
     @ sql/field.cc
        Bug#45261: Added DBUG_ASSERT to ensure object's invariant is maintained.
     @ sql/field.h
        Bug#45261: Added comment to explain what member is for.
     @ sql/sql_select.cc
        Bug#45261: Fix: Using new non-truncating function.
[3 Jul 2009 18:05] Davi Arnaut
Taking from Martin as he went on vacation.
[4 Jul 2009 4:06] 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/77958

2994 Davi Arnaut	2009-07-04
      Bug#45261: Crash, stored procedure + decimal
      
      The problem was that creating a DECIMAL column from decimal
      value could lead to a assertion as decimal values can have
      a higher precision than those attached to a table. The assert
      could be triggered by creating a table from a decimal with
      a large (> 30) scale.
      
      The solution is to ensure that truncation procedure is executed
      when deducing a DECIMAL column from a decimal value of higher
      precision. If the integer part is equal to or bigger than the
      maximum precision for the DECIMAL type (65), the integer part
      is truncated to fit and the fractional becomes zero. Otherwise,
      the fractional part is truncated to fit into the space left
      after the integer part is copied.
      
      This patch borrows code and ideas from Martin Hansson's patch.
     @ mysql-test/r/type_newdecimal.result
        Add test case result for Bug#45261
     @ mysql-test/t/type_newdecimal.test
        Add test case for Bug#45261
     @ sql/field.cc
        Added DBUG_ASSERT to ensure object's invariant is maintained.
     @ sql/field.h
        Explain member variable.
     @ sql/sql_select.cc
        Implement new truncation procedure.
[8 Jul 2009 13:19] 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/78208

3013 Davi Arnaut	2009-07-08
      Bug#45261: Crash, stored procedure + decimal
      
      The problem was that creating a DECIMAL column from decimal
      value could lead to a assertion as decimal values can have
      a higher precision than those attached to a table. The assert
      could be triggered by creating a table from a decimal with
      a large (> 30) scale. Also, there was a problem in calculating
      the number of digits in the integral and fractional parts if
      both exceeded the maximum number of digits permitted by the
      new decimal type.
      
      The solution is to ensure that truncation procedure is executed
      when deducing a DECIMAL column from a decimal value of higher
      precision. If the integer part is equal to or bigger than the
      maximum precision for the DECIMAL type (65), the integer part
      is truncated to fit and the fractional becomes zero. Otherwise,
      the fractional part is truncated to fit into the space left
      after the integer part is copied.
      
      This patch borrows code and ideas from Martin Hansson's patch.
     @ mysql-test/r/type_newdecimal.result
        Add test case result for Bug#45261. Also, update test case to
        reflect that a additive operation increases the precision of
        the resulting type by 1.
     @ mysql-test/t/type_newdecimal.test
        Add test case for Bug#45261
     @ sql/field.cc
        Added DBUG_ASSERT to ensure object's invariant is maintained.
     @ sql/field.h
        Explain member variable.
     @ sql/item.cc
        The precision should only be capped when storing the value
        on a table. Also, this makes it impossible to calculate the
        integer part if Item::decimals (the scale) is larger then the
        precision.
        
        Implement method to create a field to hold a decimal value from
        an item.
     @ sql/item.h
        Add method to create a new decimal field.
     @ sql/item_cmpfunc.cc
        Do not limit the precision. It will be capped later.
     @ sql/item_func.cc
        Use new method.
     @ sql/my_decimal.h
        The integer part could be improperly calculated for a decimal
        with 31 digits in the fractional part.
     @ sql/sql_select.cc
        Use new method.
[8 Jul 2009 13:21] 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/78209

3013 Davi Arnaut	2009-07-07
      Bug#45261: Crash, stored procedure + decimal
      
      The problem was that creating a DECIMAL column from decimal
      value could lead to a assertion as decimal values can have
      a higher precision than those attached to a table. The assert
      could be triggered by creating a table from a decimal with
      a large (> 30) scale. Also, there was a problem in calculating
      the number of digits in the integral and fractional parts if
      both exceeded the maximum number of digits permitted by the
      new decimal type.
      
      The solution is to ensure that truncation procedure is executed
      when deducing a DECIMAL column from a decimal value of higher
      precision. If the integer part is equal to or bigger than the
      maximum precision for the DECIMAL type (65), the integer part
      is truncated to fit and the fractional becomes zero. Otherwise,
      the fractional part is truncated to fit into the space left
      after the integer part is copied.
      
      This patch borrows code and ideas from Martin Hansson's patch.
     @ mysql-test/r/type_newdecimal.result
        Add test case result for Bug#45261. Also, update test case to
        reflect that a additive operation increases the precision of
        the resulting type by 1.
     @ mysql-test/t/type_newdecimal.test
        Add test case for Bug#45261
     @ sql/field.cc
        Added DBUG_ASSERT to ensure object's invariant is maintained.
     @ sql/field.h
        Explain member variable.
     @ sql/item.cc
        The precision should only be capped when storing the value
        on a table. Also, this makes it impossible to calculate the
        integer part if Item::decimals (the scale) is larger then the
        precision.
        
        Implement method to create a field to hold a decimal value from
        an item.
     @ sql/item.h
        Add method to create a new decimal field.
     @ sql/item_cmpfunc.cc
        Do not limit the precision. It will be capped later.
     @ sql/item_func.cc
        Use new method.
     @ sql/my_decimal.h
        The integer part could be improperly calculated for a decimal
        with 31 digits in the fractional part.
     @ sql/sql_select.cc
        Use new method.
[24 Jul 2009 1:03] 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/79216

3036 Davi Arnaut	2009-07-23
      Bug#45261: Crash, stored procedure + decimal
      
      The problem was that creating a DECIMAL column from decimal
      value could lead to a assertion as decimal values can have
      a higher precision than those attached to a table. The assert
      could be triggered by creating a table from a decimal with
      a large (> 30) scale. Also, there was a problem in calculating
      the number of digits in the integral and fractional parts if
      both exceeded the maximum number of digits permitted by the
      new decimal type.
      
      The solution is to ensure that truncation procedure is executed
      when deducing a DECIMAL column from a decimal value of higher
      precision. If the integer part is equal to or bigger than the
      maximum precision for the DECIMAL type (65), the integer part
      is truncated to fit and the fractional becomes zero. Otherwise,
      the fractional part is truncated to fit into the space left
      after the integer part is copied.
      
      This patch borrows code and ideas from Martin Hansson's patch.
     @ mysql-test/r/type_newdecimal.result
        Add test case result for Bug#45261. Also, update test case to
        reflect that a additive operation increases the precision of
        the resulting type by 1.
     @ mysql-test/t/type_newdecimal.test
        Add test case for Bug#45261
     @ sql/field.cc
        Added DBUG_ASSERT to ensure object's invariant is maintained.
     @ sql/field.h
        Explain member variable.
     @ sql/item.cc
        The precision should only be capped when storing the value
        on a table. Also, this makes it impossible to calculate the
        integer part if Item::decimals (the scale) is larger then the
        precision.
        
        Implement method to create a field to hold a decimal value from
        an item.
     @ sql/item.h
        Add method to create a new decimal field.
        Simplify calculation of integer part.
     @ sql/item_cmpfunc.cc
        Do not limit the precision. It will be capped later.
     @ sql/item_func.cc
        Use new method for allocating a new decimal field.
        Add a specialized method for retrieving the precision
        of a user variable item.
     @ sql/item_func.h
        Add method.
     @ sql/item_sum.cc
        Use new method for allocating a new decimal field.
     @ sql/my_decimal.h
        The integer part could be improperly calculated for a decimal
        with 31 digits in the fractional part.
     @ sql/sql_select.cc
        Use new method which truncates the integer or decimal parts
        as needed.
[11 Aug 2009 22:12] 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/80635

3063 Davi Arnaut	2009-08-11
      Bug#45261: Crash, stored procedure + decimal
      
      The problem was that creating a DECIMAL column from a decimal
      value could lead to a failed assertion as decimal values can
      have a higher precision than those attached to a table. The
      assert could be triggered by creating a table from a decimal
      with a large (> 30) scale. Also, there was a problem in
      calculating the number of digits in the integral and fractional
      parts if both exceeded the maximum number of digits permitted
      by the new decimal type.
      
      The solution is to ensure that truncation procedure is executed
      when deducing a DECIMAL column from a decimal value of higher
      precision. If the integer part is equal to or bigger than the
      maximum precision for the DECIMAL type (65), the integer part
      is truncated to fit and the fractional becomes zero. Otherwise,
      the fractional part is truncated to fit into the space left
      after the integer part is copied.
      
      This patch borrows code and ideas from Martin Hansson's patch.
     @ mysql-test/r/type_newdecimal.result
        Add test case result for Bug#45261. Also, update test case to
        reflect that an additive operation increases the precision of
        the resulting type by 1.
     @ mysql-test/t/type_newdecimal.test
        Add test case for Bug#45261
     @ sql/field.cc
        Added DBUG_ASSERT to ensure object's invariant is maintained.
        Implement method to create a field to hold a decimal value
        from an item.
     @ sql/field.h
        Explain member variable. Add method to create a new decimal field.
     @ sql/item.cc
        The precision should only be capped when storing the value
        on a table. Also, this makes it impossible to calculate the
        integer part if Item::decimals (the scale) is larger than the
        precision.
     @ sql/item.h
        Simplify calculation of integer part.
     @ sql/item_cmpfunc.cc
        Do not limit the precision. It will be capped later.
     @ sql/item_func.cc
        Use new method for allocating a new decimal field.
        Add a specialized method for retrieving the precision
        of a user variable item.
     @ sql/item_func.h
        Add method to return the precision of a user variable.
     @ sql/item_sum.cc
        Use new method for allocating a new decimal field.
     @ sql/my_decimal.h
        The integer part could be improperly calculated for a decimal
        with 31 digits in the fractional part.
     @ sql/sql_select.cc
        Use new method which truncates the integer or decimal parts
        as needed.
[24 Aug 2009 20:27] Davi Arnaut
Queued to 5.1-bugteam
[2 Sep 2009 16:42] Bugs System
Pushed into 5.1.39 (revid:joro@sun.com-20090902154533-8actmfcsjfqovgsb) (version source revid:davi.arnaut@sun.com-20090824194708-2rjutuzu0gb1wk2d) (merge vers: 5.1.39) (pib:11)
[4 Sep 2009 19:33] Paul Dubois
Noted in 5.1.39 changelog.

Truncation of DECIMAL values could lead to assertion failures; for
example, when deducing the type of a table column from a literal
DECIMAL value. 

Setting report to NDI pending push into 5.4.x.
[14 Sep 2009 16:06] Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (version source revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (merge vers: 5.4.4-alpha) (pib:11)
[14 Sep 2009 19:53] Paul Dubois
Noted in 5.4.4 changelog.
[1 Oct 2009 5:59] Bugs System
Pushed into 5.1.39-ndb-6.3.28 (revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (version source revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (merge vers: 5.1.39-ndb-6.3.28) (pib:11)
[1 Oct 2009 7:25] Bugs System
Pushed into 5.1.39-ndb-7.0.9 (revid:jonas@mysql.com-20091001072547-kv17uu06hfjhgjay) (version source revid:jonas@mysql.com-20091001071652-irejtnumzbpsbgk2) (merge vers: 5.1.39-ndb-7.0.9) (pib:11)
[1 Oct 2009 13:25] Bugs System
Pushed into 5.1.39-ndb-7.1.0 (revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (version source revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (merge vers: 5.1.39-ndb-7.1.0) (pib:11)
[2 Oct 2009 0:16] Paul Dubois
Moved 5.4 changelog entry from 5.4.4 to 5.4.3.
[5 Oct 2009 10:50] Bugs System
Pushed into 5.1.39-ndb-6.2.19 (revid:jonas@mysql.com-20091005103850-dwij2dojwpvf5hi6) (version source revid:jonas@mysql.com-20090930185117-bhud4ek1y0hsj1nv) (merge vers: 5.1.39-ndb-6.2.19) (pib:11)
[2 Nov 2009 11:22] 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/88920

3172 Davi Arnaut	2009-11-02
      Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF
      Bug#45261: Crash, stored procedure + decimal
      
      Revert fix for Bug#45261 due to unforeseen bugs.
[4 Nov 2009 9:25] Bugs System
Pushed into 5.1.41 (revid:joro@sun.com-20091104092152-qz96bzlf2o1japwc) (version source revid:kristofer.pettersson@sun.com-20091103162305-08l4gkeuif2ozsoj) (merge vers: 5.1.41) (pib:13)
[11 Nov 2009 6:51] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091110093407-rw5g8dys2baqkt67) (version source revid:alik@sun.com-20091109080109-7dxapd5y5pxlu08w) (merge vers: 6.0.14-alpha) (pib:13)
[11 Nov 2009 6:59] Bugs System
Pushed into 5.5.0-beta (revid:alik@sun.com-20091109115615-nuohp02h8mdrz8m2) (version source revid:alik@sun.com-20091105121316-hgdduu5vqdpbawf8) (merge vers: 5.5.0-beta) (pib:13)
[13 Nov 2009 11:14] 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/90329

3199 Georgi Kodinov	2009-11-13
      Bug #45261 : Crash, stored procedure + decimal
      Bug #48370  Absolutely wrong calculations with GROUP BY and
        decimal fields when using IF
      
      Added the test cases in the above two bugs for regression
      testing.
[13 Nov 2009 16:20] 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/90377

3199 Georgi Kodinov	2009-11-13
      Bug #45261 : Crash, stored procedure + decimal
      Bug #48370  Absolutely wrong calculations with GROUP BY and
        decimal fields when using IF
      
      Added the test cases in the above two bugs for regression
      testing.
      Added additional tests that demonstrate a incomplete fix.
      Added a new factory method for Field_new_decimal to 
      create a field from an (decimal returning) Item.
      In the new method made sure that all the precision and 
      length variables are capped in a proper way. 
      This is required because Item's can have larger precision
      than the decimal fields and thus need to be capped when
      creating a field based on an Item type.
[20 Nov 2009 10:11] 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/91049

3199 Georgi Kodinov	2009-11-20
      Bug #45261 : Crash, stored procedure + decimal
      Bug #48370  Absolutely wrong calculations with GROUP BY and
        decimal fields when using IF
      
      Added the test cases in the above two bugs for regression
      testing.
      Added additional tests that demonstrate a incomplete fix.
      Added a new factory method for Field_new_decimal to 
      create a field from an (decimal returning) Item.
      In the new method made sure that all the precision and 
      length variables are capped in a proper way. 
      This is required because Item's can have larger precision
      than the decimal fields and thus need to be capped when
      creating a field based on an Item type.
      Fixed the wrong typecast to Item_decimal.
[24 Nov 2009 14:42] 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/91425

3219 Georgi Kodinov	2009-11-20
      Bug #45261 : Crash, stored procedure + decimal
      Bug #48370  Absolutely wrong calculations with GROUP BY and
        decimal fields when using IF
      
      Added the test cases in the above two bugs for regression
      testing.
      Added additional tests that demonstrate a incomplete fix.
      Added a new factory method for Field_new_decimal to 
      create a field from an (decimal returning) Item.
      In the new method made sure that all the precision and 
      length variables are capped in a proper way. 
      This is required because Item's can have larger precision
      than the decimal fields and thus need to be capped when
      creating a field based on an Item type.
      Fixed the wrong typecast to Item_decimal.
[24 Nov 2009 15:01] Georgi Kodinov
Pushed the crash fix in 5.1-bugteam and merged to mysql-pe.
Will create a new bug for the incorrect truncation cases.
[25 Nov 2009 8:21] Georgi Kodinov
Filed bug #49089 to track the remaining part of the problem described here (the non-crashing part).
[2 Dec 2009 8:04] Bugs System
Pushed into 5.1.42 (revid:joro@sun.com-20091202080033-mndu4sxwx19lz2zs) (version source revid:davi.arnaut@sun.com-20091125130912-d7hrln14ef7y5d7i) (merge vers: 5.1.42) (pib:13)
[2 Dec 2009 21:39] Paul Dubois
Noted in 5.1.42 changelog.

Setting report pending push to 5.6.x+.
[6 Dec 2009 21:09] Elena Stepanova
See also bug#49489
[7 Dec 2009 16:50] Paul Dubois
Noted in 5.5.0, 6.0.14 changelogs.
[8 Dec 2009 9:29] Bugs System
Pushed into 5.1.43 (revid:build@mysql.com-20091208092611-pbno5awyb0v38hs7) (version source revid:build@mysql.com-20091208092611-pbno5awyb0v38hs7) (merge vers: 5.1.43) (pib:13)
[16 Dec 2009 8:41] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091216083311-xorsasf5kopjxshf) (version source revid:alik@sun.com-20091215065750-5m04ogppd5l0pol5) (merge vers: 6.0.14-alpha) (pib:14)
[16 Dec 2009 8:47] Bugs System
Pushed into 5.5.0-beta (revid:alik@sun.com-20091216082430-s0gtzibcgkv4pqul) (version source revid:alik@sun.com-20091211070127-kl8uvlrv9cr11kva) (merge vers: 5.5.0-beta) (pib:14)
[16 Dec 2009 8:54] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20091216083231-rp8ecpnvkkbhtb27) (version source revid:alik@sun.com-20091212203859-fx4rx5uab47wwuzd) (merge vers: 5.6.0-beta) (pib:14)
[18 Dec 2009 10:38] Bugs System
Pushed into 5.1.41-ndb-7.1.0 (revid:jonas@mysql.com-20091218102229-64tk47xonu3dv6r6) (version source revid:jonas@mysql.com-20091218095730-26gwjidfsdw45dto) (merge vers: 5.1.41-ndb-7.1.0) (pib:15)
[18 Dec 2009 10:54] Bugs System
Pushed into 5.1.41-ndb-6.2.19 (revid:jonas@mysql.com-20091218100224-vtzr0fahhsuhjsmt) (version source revid:jonas@mysql.com-20091217101452-qwzyaig50w74xmye) (merge vers: 5.1.41-ndb-6.2.19) (pib:15)
[18 Dec 2009 11:08] Bugs System
Pushed into 5.1.41-ndb-6.3.31 (revid:jonas@mysql.com-20091218100616-75d9tek96o6ob6k0) (version source revid:jonas@mysql.com-20091217154335-290no45qdins5bwo) (merge vers: 5.1.41-ndb-6.3.31) (pib:15)
[18 Dec 2009 11:23] Bugs System
Pushed into 5.1.41-ndb-7.0.11 (revid:jonas@mysql.com-20091218101303-ga32mrnr15jsa606) (version source revid:jonas@mysql.com-20091218064304-ezreonykd9f4kelk) (merge vers: 5.1.41-ndb-7.0.11) (pib:15)
[12 Mar 2010 14:18] Bugs System
Pushed into 5.1.44-ndb-7.0.14 (revid:jonas@mysql.com-20100312135944-t0z8s1da2orvl66x) (version source revid:jonas@mysql.com-20100312115609-woou0te4a6s4ae9y) (merge vers: 5.1.44-ndb-7.0.14) (pib:16)
[12 Mar 2010 14:33] Bugs System
Pushed into 5.1.44-ndb-6.2.19 (revid:jonas@mysql.com-20100312134846-tuqhd9w3tv4xgl3d) (version source revid:jonas@mysql.com-20100312060623-mx6407w2vx76h3by) (merge vers: 5.1.44-ndb-6.2.19) (pib:16)
[12 Mar 2010 14:50] Bugs System
Pushed into 5.1.44-ndb-6.3.33 (revid:jonas@mysql.com-20100312135724-xcw8vw2lu3mijrhn) (version source revid:jonas@mysql.com-20100312103652-snkltsd197l7q2yg) (merge vers: 5.1.44-ndb-6.3.33) (pib:16)