Bug #31471 decimal_bin_size: Assertion `scale >= 0 && precision > 0 && scale <= precision'
Submitted: 9 Oct 2007 8:48 Modified: 30 Oct 2007 1:14
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Data Types Severity:S2 (Serious)
Version:5.0.50-debug, 5.1.23-debug OS:Any
Assigned to: Gleb Shchepa CPU Architecture:Any
Tags: assertion, ifnull

[9 Oct 2007 8:48] Shane Bester
Version: '5.1.23-beta-debug'  socket: '/tmp/mysql.sock'  port: 3306  yes
mysqld: decimal.c:1462: decimal_bin_size: Assertion `scale >= 0 && precision > 0 && scale <= precision' failed.
071009 10:28:10 - mysqld got signal 6;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337620 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x8dd5660
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x42879e78, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x820147b handle_segfault + 541
0x4003f105 _end + 931835445
0x4012d1f1 _end + 932810529
0x4003c44b _end + 931823995
0x4012cf84 _end + 932809908
0x4012e498 _end + 932815304
0x40126223 _end + 932781907
0x8506224 decimal_bin_size + 136
0x81d5d53 Field_new_decimal::Field_new_decimal(unsigned char*, unsigned int, unsigned char*, unsigned char, Field::utype, char const*, unsigned char, bool, bool) + 201
0x8159ce9 Item::tmp_table_field_from_field_type(st_table*, bool) + 461
0x8189d98 Item_func_ifnull::tmp_table_field(st_table*) + 32
0x828703e _Z23create_table_from_itemsP3THDP24st_ha_create_informationP10TABLE_LISTP10Alter_infoP4ListI4ItemEPP13st_mysql_lockP13TABLEOP_H + 560
0x828761b select_create::prepare(List<Item>&, st_select_lex_unit*) + 303
0x825d38b JOIN::prepare(Item***, TABLE_LIST*, unsigned int, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*) + 2703
0x8261b11 _Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select + 529
0x825c69d handle_select(THD*, st_lex*, select_result*, unsigned long) + 365
0x820f8e9 mysql_execute_command(THD*) + 5209
0x82178b0 mysql_parse(THD*, char const*, unsigned int, char const**) + 372
0x820cf60 dispatch_command(enum_server_command, THD*, char*, unsigned int) + 2354
0x820c622 do_command(THD*) + 600
0x820b01d handle_one_connection + 255
0x40038e31 _end + 931810145
0x401be6fa _end + 933405738
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.html
and follow instructions on how to resolve the stack trace.
Resolved stack trace is much more helpful in diagnosing the
problem, so please do resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8df5270 = create temporary table t select (ifnull(`a`,`b`)) from `t1`
The manual page at http://www.mysql.com/doc/en/Crashing.html contains

How to repeat:
drop table if exists `t1`;
create table `t1` (`a` decimal (1,0) zerofill ,`b` decimal (1,0) zerofill)engine=heap;
insert into `t1`(`a`,`b`) values (0,0);
create temporary table t select (ifnull(`a`,`b`)) from `t1`;
[9 Oct 2007 8:50] Shane Bester
see related Bug #18984
[10 Oct 2007 15: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:


ChangeSet@1.2537, 2007-10-10 20:14:29+05:00, gshchepa@gleb.loc +4 -0
  Fixed bug #31471: decimal_bin_size: Assertion `scale >= 0 &&
                    precision > 0 && scale <= precision'.
  A sign of a resulting item of the IFNULL function was not
  updated and the maximal length of this result was calculated
  improperly. Correct algorithm was copy&pasted from the IF
  function implementation.
[29 Oct 2007 8:43] Bugs System
Pushed into 5.0.52
[29 Oct 2007 8:47] Bugs System
Pushed into 5.1.23-beta
[29 Oct 2007 8:51] Bugs System
Pushed into 6.0.4-alpha
[30 Oct 2007 1:14] Paul Dubois
Noted in 5.0.52, 5.1.23, 6.0.4 changelogs.