[MDEV-4241] Assertion failure: scale >= 0 && precision > 0 && scale <= precision in decimal_bin_size Created: 2013-03-05  Updated: 2013-03-07  Resolved: 2013-03-07

Status: Closed
Project: MariaDB Server
Component/s: None
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

Type: Bug Priority: Critical
Reporter: Raif Atef Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: None
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
—
Also reproducible on Ubuntu 12.04 x64_64

Attachments: File mysql_bug.7z    

 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.

 Comments   
Comment by Raif Atef [ 2013-03-05 ]

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.

Comment by Oleksandr Byelkin [ 2013-03-05 ]

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

Comment by Elena Stepanova [ 2013-03-05 ]

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

Comment by Raif Atef [ 2013-03-05 ]

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.

Comment by Elena Stepanova [ 2013-03-05 ]

>> 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.

Comment by Oleksandr Byelkin [ 2013-03-05 ]

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.

Comment by Sergei Golubchik [ 2013-03-05 ]

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

Comment by Oleksandr Byelkin [ 2013-03-06 ]

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;

Comment by Oleksandr Byelkin [ 2013-03-06 ]

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

Comment by Oleksandr Byelkin [ 2013-03-06 ]

The problem is that Firld_enum inherit decimals() from Field_str

Comment by Oleksandr Byelkin [ 2013-03-06 ]

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

Comment by Oleksandr Byelkin [ 2013-03-06 ]

Pushed.

Generated at Thu Feb 08 06:54:53 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.