| 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: | |
| Category: | MySQL Server: Stored Routines | Severity: | S3 (Non-critical) |
| Version: | 5.1,5.4 | OS: | Any |
| Assigned to: | Georgi Kodinov | CPU Architecture: | Any |
[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)
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.