[MDEV-4241] Assertion failure: scale >= 0 && precision > 0 && scale <= precision in decimal_bin_size - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.0.1, 5.5.29, 5.5.28a-galera, 5.3.12
Fix Version/s: 10.0.2, 5.5.31, 5.3.13
Component/s: None
Labels:
None
Environment:

Hide
Windows 8 32-bit fully patched and updated.
MariaDB installed in both cases from official MSI installer.
Core 2 Duo P8600 CPU
4 GB DDR2 800MHZ Dual Channel RAM
Seagate Momentus XT 750 GB
---
Also reproducible on Ubuntu 12.04 x64_64

Show
Windows 8 32-bit fully patched and updated. MariaDB installed in both cases from official MSI installer. Core 2 Duo P8600 CPU 4 GB DDR2 800MHZ Dual Channel RAM Seagate Momentus XT 750 GB --- Also reproducible on Ubuntu 12.04 x64_64

Description

The initial description is below.

Simplified test case:

CREATE TABLE t1 (

  f1 enum('1','2','3','4','5')

) ENGINE=MyISAM;

INSERT INTO t1 VALUES (1),(2);

SELECT AVG(f1) FROM t1;

mysqld: decimal.c:1467: decimal_bin_size: Assertion `scale >= 0 && precision > 0 && scale <= precision' failed.

[ERROR] mysqld got signal 6 ;

#5  0x00007fcabef28b8b in __GI_abort () at abort.c:91

#6  0x00007fcabef1e0ee in __assert_fail_base (fmt=<optimized out>, assertion=0xed6e58 "scale >= 0 && precision > 0 && scale <= precision", file=0xed6c00 "decimal.c", line=<optimized out>, function=<optimized out>) at assert.c:94

#7  0x00007fcabef1e192 in __GI___assert_fail (assertion=0xed6e58 "scale >= 0 && precision > 0 && scale <= precision", file=0xed6c00 "decimal.c", line=1467, function=0xed7050 "decimal_bin_size") at assert.c:103

#8  0x0000000000bd6de1 in decimal_bin_size (precision=27, scale=31) at decimal.c:1467

#9  0x00000000005a9eb4 in my_decimal_get_binary_size (precision=27, scale=31) at my_decimal.h:236

#10 0x00000000005a2334 in Item_sum_avg::fix_length_and_dec (this=0x7fcaa40190e8) at item_sum.cc:1243

#11 0x00000000005a02d9 in Item_sum_num::fix_fields (this=0x7fcaa40190e8, thd=0x29f88b8, ref=0x7fcaa40192b8) at item_sum.cc:596

#12 0x00000000006ed7a9 in setup_fields (thd=0x29f88b8, ref_pointer_array=0x7fcaa4019ce0, fields=..., mark_used_columns=MARK_COLUMNS_READ, sum_func_list=0x7fcaa4019ad0, allow_sum_func=true) at sql_base.cc:7858

#13 0x0000000000706181 in JOIN::prepare (this=0x7fcaa40197d8, rref_pointer_array=0x29fb5a8, tables_init=0x7fcaa4019310, wild_num=0, conds_init=0x0, og_num=0, order_init=0x0, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x29fb350, unit_arg=0x29fae48) at sql_select.cc:666

#14 0x000000000070eadb in mysql_select (thd=0x29f88b8, rref_pointer_array=0x29fb5a8, tables=0x7fcaa4019310, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147764736, result=0x7fcaa40197b8, unit=0x29fae48, select_lex=0x29fb350) at sql_select.cc:2970

#15 0x0000000000705605 in handle_select (thd=0x29f88b8, lex=0x29fada8, result=0x7fcaa40197b8, setup_tables_done_option=0) at sql_select.cc:288

#16 0x0000000000691912 in execute_sqlcom_select (thd=0x29f88b8, all_tables=0x7fcaa4019310) at sql_parse.cc:5172

#17 0x00000000006886da in mysql_execute_command (thd=0x29f88b8) at sql_parse.cc:2305

#18 0x000000000069439c in mysql_parse (thd=0x29f88b8, rawbuf=0x7fcaa4018f40 "SELECT AVG(f1) FROM t1", length=22, found_semicolon=0x7fcabdda17e0) at sql_parse.cc:6173

#19 0x0000000000685df7 in dispatch_command (command=COM_QUERY, thd=0x29f88b8, packet=0x2a72b69 "SELECT AVG(f1) FROM t1", packet_length=22) at sql_parse.cc:1243

#20 0x0000000000685068 in do_command (thd=0x29f88b8) at sql_parse.cc:923

#21 0x0000000000681f02 in handle_one_connection (arg=0x29f88b8) at sql_connect.cc:1231

#22 0x00007fcabfab9e9a in start_thread (arg=0x7fcabdda2700) at pthread_create.c:308

#23 0x00007fcabefe2cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Reproducible with the default optimizer_switch as well as with all OFF values.

revision-id: psergey@askmonty.org-20130301042335-x16j7uo1dwxxgqs9

revno: 3632

branch-nick: 5.3

Also reproducible on current 5.5, 10.0.
Not reproducible on 5.2, mysql/5.5, mysql/5.6.

=========================================

Initial description

In the attachment, I have:

1. a schema with sample data and 2 queries that run on it causing MariaDB to crash.
2. Own compiled MariaDB mysqld 5.5.29 win32 binary in debug mode using CMAKE and VS2012 32-bit compiler which also shows issue.
3. my.ini from crashing environment
4. core dump of debug version
5. err file containing stack trace.

Sometimes it will return a result once or twice before crashing.

Crash is 100% reproducible.
5.5.28a and 5.5.29 exhibit issue, own built 5.5.29 from source on windows with CMAKE and VS2012 C++ compiler (32-bit) with full debug symbols also crashes.

This is my first MySQL-related bug report, I hope I've done everything right.

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

mysql_bug.7z
7.15 MB
2013-03-05 00:22

Activity

Ascending order - Click to sort in descending order

Raif Atef created issue - 2013-03-05 00:22

Elena Stepanova made changes - 2013-03-05 00:26

Field	Original Value	New Value
Assignee		Elena Stepanova [ elenst ]

Elena Stepanova made changes - 2013-03-05 03:12

Fix Version/s		10.0.2 [ 11900 ]
Fix Version/s		5.5.31 [ 12700 ]
Fix Version/s		5.3.13 [ 12602 ]
Affects Version/s		5.3.12 [ 12000 ]
Affects Version/s		10.0.1 [ 11400 ]
Assignee	Elena Stepanova [ elenst ]	Oleksandr Byelkin [ sanja ]
Description	In the attachment, I have: 1. a schema with sample data and 2 queries that run on it causing MariaDB to crash. 2. Own compiled MariaDB mysqld 5.5.29 win32 binary in debug mode using CMAKE and VS2012 32-bit compiler which also shows issue. 3. my.ini from crashing environment 4. core dump of debug version 5. err file containing stack trace. Sometimes it will return a result once or twice before crashing. Crash is 100% reproducible. 5.5.28a and 5.5.29 exhibit issue, own built 5.5.29 from source on windows with CMAKE and VS2012 C++ compiler (32-bit) with full debug symbols also crashes. This is my first MySQL-related bug report, I hope I've done everything right.	The initial description is below. Simplified test case: {code:sql} CREATE TABLE t1 ( f1 enum('1','2','3','4','5') ) ENGINE=MyISAM; INSERT INTO t1 VALUES (1),(2); SELECT AVG(f1) FROM t1; {code} {noformat} mysqld: decimal.c:1467: decimal_bin_size: Assertion `scale >= 0 && precision > 0 && scale <= precision' failed. [ERROR] mysqld got signal 6 ; {noformat} {noformat} #5 0x00007fcabef28b8b in __GI_abort () at abort.c:91 #6 0x00007fcabef1e0ee in __assert_fail_base (fmt=<optimized out>, assertion=0xed6e58 "scale >= 0 && precision > 0 && scale <= precision", file=0xed6c00 "decimal.c", line=<optimized out>, function=<optimized out>) at assert.c:94 #7 0x00007fcabef1e192 in __GI___assert_fail (assertion=0xed6e58 "scale >= 0 && precision > 0 && scale <= precision", file=0xed6c00 "decimal.c", line=1467, function=0xed7050 "decimal_bin_size") at assert.c:103 #8 0x0000000000bd6de1 in decimal_bin_size (precision=27, scale=31) at decimal.c:1467 #9 0x00000000005a9eb4 in my_decimal_get_binary_size (precision=27, scale=31) at my_decimal.h:236 #10 0x00000000005a2334 in Item_sum_avg::fix_length_and_dec (this=0x7fcaa40190e8) at item_sum.cc:1243 #11 0x00000000005a02d9 in Item_sum_num::fix_fields (this=0x7fcaa40190e8, thd=0x29f88b8, ref=0x7fcaa40192b8) at item_sum.cc:596 #12 0x00000000006ed7a9 in setup_fields (thd=0x29f88b8, ref_pointer_array=0x7fcaa4019ce0, fields=..., mark_used_columns=MARK_COLUMNS_READ, sum_func_list=0x7fcaa4019ad0, allow_sum_func=true) at sql_base.cc:7858 #13 0x0000000000706181 in JOIN::prepare (this=0x7fcaa40197d8, rref_pointer_array=0x29fb5a8, tables_init=0x7fcaa4019310, wild_num=0, conds_init=0x0, og_num=0, order_init=0x0, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x29fb350, unit_arg=0x29fae48) at sql_select.cc:666 #14 0x000000000070eadb in mysql_select (thd=0x29f88b8, rref_pointer_array=0x29fb5a8, tables=0x7fcaa4019310, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147764736, result=0x7fcaa40197b8, unit=0x29fae48, select_lex=0x29fb350) at sql_select.cc:2970 #15 0x0000000000705605 in handle_select (thd=0x29f88b8, lex=0x29fada8, result=0x7fcaa40197b8, setup_tables_done_option=0) at sql_select.cc:288 #16 0x0000000000691912 in execute_sqlcom_select (thd=0x29f88b8, all_tables=0x7fcaa4019310) at sql_parse.cc:5172 #17 0x00000000006886da in mysql_execute_command (thd=0x29f88b8) at sql_parse.cc:2305 #18 0x000000000069439c in mysql_parse (thd=0x29f88b8, rawbuf=0x7fcaa4018f40 "SELECT AVG(f1) FROM t1", length=22, found_semicolon=0x7fcabdda17e0) at sql_parse.cc:6173 #19 0x0000000000685df7 in dispatch_command (command=COM_QUERY, thd=0x29f88b8, packet=0x2a72b69 "SELECT AVG(f1) FROM t1", packet_length=22) at sql_parse.cc:1243 #20 0x0000000000685068 in do_command (thd=0x29f88b8) at sql_parse.cc:923 #21 0x0000000000681f02 in handle_one_connection (arg=0x29f88b8) at sql_connect.cc:1231 #22 0x00007fcabfab9e9a in start_thread (arg=0x7fcabdda2700) at pthread_create.c:308 #23 0x00007fcabefe2cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 {noformat} Reproducible with the default optimizer_switch as well as with all OFF values. {noformat} revision-id: psergey@askmonty.org-20130301042335-x16j7uo1dwxxgqs9 revno: 3632 branch-nick: 5.3 {noformat} Also reproducible on current 5.5, 10.0. Not reproducible on 5.2, mysql/5.5, mysql/5.6. ========================================= h3. Initial description In the attachment, I have: 1. a schema with sample data and 2 queries that run on it causing MariaDB to crash. 2. Own compiled MariaDB mysqld 5.5.29 win32 binary in debug mode using CMAKE and VS2012 32-bit compiler which also shows issue. 3. my.ini from crashing environment 4. core dump of debug version 5. err file containing stack trace. Sometimes it will return a result once or twice before crashing. Crash is 100% reproducible. 5.5.28a and 5.5.29 exhibit issue, own built 5.5.29 from source on windows with CMAKE and VS2012 C++ compiler (32-bit) with full debug symbols also crashes. This is my first MySQL-related bug report, I hope I've done everything right.
Environment	Windows 8 32-bit fully patched and updated. MariaDB installed in both cases from official MSI installer. Core 2 Duo P8600 CPU 4 GB DDR2 800MHZ Dual Channel RAM Seagate Momentus XT 750 GB	Windows 8 32-bit fully patched and updated. MariaDB installed in both cases from official MSI installer. Core 2 Duo P8600 CPU 4 GB DDR2 800MHZ Dual Channel RAM Seagate Momentus XT 750 GB --- Also reproducible on Ubuntu 12.04 x64_64
Summary	Crash: my_decimal_get_binary_size, assert: scale >= 0 && precision > 0 && scale <= precision	Assertion failure: my_decimal_get_binary_size, assert: scale >= 0 && precision > 0 && scale <= precision

Elena Stepanova made changes - 2013-03-05 03:13

Summary

Assertion failure: my_decimal_get_binary_size, assert: scale >= 0 && precision > 0 && scale <= precision

Assertion failure: scale >= 0 && precision > 0 && scale <= precision in decimal_bin_size

Raif Atef added a comment - 2013-03-05 12:12

Strangely enough, the simplified test case only crashes for me on the debug build, and not on the official 5.5.29 release build.

The 1st test query (crash_query_1.sql) stops crashing if I add a CAST(rating.RTG_NOTE as INT) inside the AVG function call.
I'm starting to imagine there's multiple code paths, one of which is not hit in the release build in the simplified test case.

Raif Atef added a comment - 2013-03-05 12:12 Strangely enough, the simplified test case only crashes for me on the debug build, and not on the official 5.5.29 release build. The 1st test query (crash_query_1.sql) stops crashing if I add a CAST(rating.RTG_NOTE as INT) inside the AVG function call. I'm starting to imagine there's multiple code paths, one of which is not hit in the release build in the simplified test case.

Oleksandr Byelkin made changes - 2013-03-05 13:19

Status

Open [ 1 ]

In Progress [ 3 ]

Oleksandr Byelkin added a comment - 2013-03-05 14:20

To make it working independent from windows 'GSR' should be changed to 'gsr' in both queries.

Oleksandr Byelkin added a comment - 2013-03-05 14:20 To make it working independent from windows 'GSR' should be changed to 'gsr' in both queries.

Oleksandr Byelkin made changes - 2013-03-05 14:21

Status

In Progress [ 3 ]

Open [ 1 ]

Elena Stepanova added a comment - 2013-03-05 14:22

You can also use --lower_case_table_names=1 for the same purpose

Elena Stepanova added a comment - 2013-03-05 14:22 You can also use --lower_case_table_names=1 for the same purpose

Raif Atef added a comment - 2013-03-05 14:30

Yes, I noticed that in the DDL schema I posted, "gsr" was in lower case, my apologies for any confusion. This was due to the export tool I used.

In the actual schema, the table name is created in the create table statement with "GSR" uppercase and it works correctly.
Regardless, changing the casing does not avoid the crash, it still happens, so the casing of the table name in the query or the schema is not related to this bug.

Raif Atef added a comment - 2013-03-05 14:30 Yes, I noticed that in the DDL schema I posted, "gsr" was in lower case, my apologies for any confusion. This was due to the export tool I used. In the actual schema, the table name is created in the create table statement with "GSR" uppercase and it works correctly. Regardless, changing the casing does not avoid the crash, it still happens, so the casing of the table name in the query or the schema is not related to this bug.

Oleksandr Byelkin made changes - 2013-03-05 14:44

Status

Open [ 1 ]

In Progress [ 3 ]

Elena Stepanova added a comment - 2013-03-05 15:13 - edited

>> Yes, I noticed that in the DDL schema I posted, "gsr" was in lower case, my apologies for any confusion

Not your fault, that's how it works on Windows. The option --lower_case_table_names helps to make such things portable. And no, the casing has nothing to do with the crash, of course.

Elena Stepanova added a comment - 2013-03-05 15:13 - edited >> Yes, I noticed that in the DDL schema I posted, "gsr" was in lower case, my apologies for any confusion Not your fault, that's how it works on Windows. The option --lower_case_table_names helps to make such things portable. And no, the casing has nothing to do with the crash, of course.

Oleksandr Byelkin added a comment - 2013-03-05 15:31 - edited

Please don't take my comment to heart, it was mostly for me to avoid problem if I decide to repeat it after some time. The thing is trivial to find and fix and it is not the first time I've met it, just it will economize me 5-10 min if I'll decide to repeat it in several weeks.

Oleksandr Byelkin added a comment - 2013-03-05 15:31 - edited Please don't take my comment to heart, it was mostly for me to avoid problem if I decide to repeat it after some time. The thing is trivial to find and fix and it is not the first time I've met it, just it will economize me 5-10 min if I'll decide to repeat it in several weeks.

Sergei Golubchik added a comment - 2013-03-05 16:48

Sanja, please, replace this assert with three AND-ed conditions, by three separate asserts. Thanks!

Sergei Golubchik added a comment - 2013-03-05 16:48 Sanja, please, replace this assert with three AND-ed conditions, by three separate asserts. Thanks!

Oleksandr Byelkin made changes - 2013-03-06 15:14

Status

In Progress [ 3 ]

Open [ 1 ]

Oleksandr Byelkin made changes - 2013-03-06 15:14

Status

Open [ 1 ]

In Progress [ 3 ]

Oleksandr Byelkin added a comment - 2013-03-06 15:45

Reduced test suite:
CREATE TABLE t1 (
f enum('1','2','3','4','5') DEFAULT NULL
);

insert into t1 (f) values ('5'),('5');

SELECT
1,
IFNULL(FLOOR(AVG(f)), 0) AS avg_grade
FROM
t1
GROUP BY 1;

Oleksandr Byelkin added a comment - 2013-03-06 15:45 Reduced test suite: CREATE TABLE t1 ( f enum('1','2','3','4','5') DEFAULT NULL ); insert into t1 (f) values ('5'),('5'); SELECT 1, IFNULL(FLOOR(AVG(f)), 0) AS avg_grade FROM t1 GROUP BY 1;

Oleksandr Byelkin added a comment - 2013-03-06 16:16

In MySQL it is not reproducible because it has REAL type while in MariaDB it is DECIMAL

Oleksandr Byelkin added a comment - 2013-03-06 16:16 In MySQL it is not reproducible because it has REAL type while in MariaDB it is DECIMAL

Oleksandr Byelkin added a comment - 2013-03-06 20:46

The problem is that Firld_enum inherit decimals() from Field_str

Oleksandr Byelkin added a comment - 2013-03-06 20:46 The problem is that Firld_enum inherit decimals() from Field_str

Oleksandr Byelkin added a comment - 2013-03-06 21:13

fix committed for review (original test suite was checked).

Oleksandr Byelkin added a comment - 2013-03-06 21:13 fix committed for review (original test suite was checked).

Oleksandr Byelkin made changes - 2013-03-06 21:16

Status

In Progress [ 3 ]

Open [ 1 ]

Oleksandr Byelkin made changes - 2013-03-06 22:30

Status

Open [ 1 ]

In Progress [ 3 ]

Oleksandr Byelkin added a comment - 2013-03-06 22:38

Pushed.

Oleksandr Byelkin added a comment - 2013-03-06 22:38 Pushed.

Oleksandr Byelkin made changes - 2013-03-06 22:38

Status

In Progress [ 3 ]

Open [ 1 ]

Oleksandr Byelkin made changes - 2013-03-07 10:17

Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2014-06-13 15:07

Workflow

defaullt [ 26506 ]

MariaDB v2 [ 46401 ]

Rasmus Johansson (Inactive) made changes - 2015-05-18 17:51

Workflow

MariaDB v2 [ 46401 ]

MariaDB v3 [ 67105 ]

Sergei Golubchik made changes - 2021-12-06 21:38

Workflow

MariaDB v3 [ 67105 ]

MariaDB v4 [ 146489 ]

People

Assignee:: Oleksandr Byelkin

Reporter:: Raif Atef

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2013-03-05 00:22

Updated:: 2013-03-07 10:17

Resolved:: 2013-03-07 10:17

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Initial description

Attachments

Attachments

Activity

People

Dates

Git Integration