mysql 14.12 Distrib 5.0.10-beta crashes on complex join query (similar to bug 12392 ?)

mysql 14.12 Distrib 5.0.10-beta crashes on complex join query (similar to bug 12392 ?)

am 11.08.2005 06:47:26 von Timothy Redmond

I apologize if this is a repeat. I tried to send this earlier today
but I don't think it got through.

Timothy Redmond



>Description:

I have a query (see below) which will consistently cause mysqld to
crash. On the client side I see the following error:

ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>

When I look at the error log I see the following message:

mysqld got signal 10;
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.

key_buffer_size=8388600
read_buffer_size=131072
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size +
sort_buffer_size)*max_connections = 225791 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

050810 11:23:15 mysqld restarted

I attached gdb and saw the following stack trace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
[Switching to process 22801 thread 0x2d03]
0x00082608 in sortcmp (s=0x0, t=0x3847088, cs=0x3d16e0) at
sql_string.cc:724
724 (unsigned char *) t->ptr
(),t->length(), 0);
(gdb) bt
#0 0x00082608 in sortcmp (s=0x0, t=0x3847088, cs=0x3d16e0) at
sql_string.cc:724
#1 0x00361c94 in cmp_item_sort_string::cmp (this=0x38a1190,
arg=0x3847088) at item_cmpfunc.h:699
#2 0x00038790 in Item_equal::val_int (this=0x38a10e8) at
item_cmpfunc.cc:3559
#3 0x000d433c in join_read_const_table (tab=0x38a138c,
pos=0x3847c9c) at sql_select.cc:9721
#4 0x000d9604 in make_join_statistics (join=0x3847c10,
tables=0x3847c9c, conds=0x3848a00, keyuse_array=0x3848934) at
sql_select.cc:2305
#5 0x000e0c74 in JOIN::optimize (this=0x3847c10) at
sql_select.cc:656
#6 0x000e7e74 in mysql_select (thd=0x382aa00,
rref_pointer_array=0x382ad74, tables=0x3846c78, wild_num=0,
fields=@0x382acdc, conds=0x3847ac0, og_num=0, order=0x0, group=0x0,
having=0x0, proc_param=0x0, select_options=2156153344,
result=0x3847c00, unit=0x382aa50, select_lex=0x382ac50) at
sql_select.cc:2046
#7 0x000e8314 in handle_select (thd=0x382aa00, lex=0x382aa40,
result=0x3847c00, setup_tables_done_option=0) at sql_select.cc:250
#8 0x0009c778 in mysql_execute_command (thd=0x382aa00) at
sql_parse.cc:2421
#9 0x000a1dc8 in mysql_parse (thd=0x382aa00, inBuf=0x3840e10
"select assetlocat0_.id as id2_, assetlocat0_.home_address_location_id
\n as home2_340_2_, assetlocat0_.present_address_location_id as\n
present3_340_2_, addressloc1_.id as id0_, addressloc1_.city as\n"...,
length=58894912) at sql_parse.cc:5382
#10 0x000a24e4 in dispatch_command (command=58987394,
thd=0x382aa00, packet=0x24b9001 "select assetlocat0_.id as id2_,
assetlocat0_.home_address_location_id\n as home2_340_2_,
assetlocat0_.present_address_location_id as\n present3_340_2_,
addressloc1_.id as id0_, addressloc1_.city as\n"...,
packet_length=1395) at sql_parse.cc:1664
#11 0x000a34e4 in do_command (thd=0x382aa00) at sql_parse.cc:1467
#12 0x000a3eb8 in handle_one_connection (arg=0x0) at
sql_parse.cc:1116
#13 0x9002c3d4 in _pthread_body ()
Current language: auto; currently c++
(gdb)

At first this bug appeared to be similar to bug #12392 but I applied
that patch successfully (it passed the test that was included with the
patch) and my problem did not go away.

>How-To-Repeat:

This is the query:

select assetlocat0_.id as id2_,
assetlocat0_.home_address_location_id
as home2_340_2_, assetlocat0_.present_address_location_id as
present3_340_2_, addressloc1_.id as id0_, addressloc1_.city as
city341_0_, addressloc1_.code as code341_0_, addressloc1_.country
as country341_0_, addressloc1_.county as county341_0_,
addressloc1_.street as street341_0_, addressloc1_.state as
state341_0_, addressloc1_.postal_code as postal8_341_0_,
addressloc1_.name as name341_0_, addressloc1_.latitude as
latitude341_0_, addressloc1_.longitude as longitude341_0_,
addressloc1_.altitude as altitude341_0_, addressloc2_.id as id1_,
addressloc2_.city as city341_1_, addressloc2_.code as code341_1_,
addressloc2_.country as country341_1_, addressloc2_.county as
county341_1_, addressloc2_.street as street341_1_,
addressloc2_.state as state341_1_, addressloc2_.postal_code as
postal8_341_1_, addressloc2_.name as name341_1_,
addressloc2_.latitude as latitude341_1_, addressloc2_.longitude as
longitude341_1_, addressloc2_.altitude as altitude341_1_ from
asset_location assetlocat0_ left outer join address_location
addressloc1_ on
assetlocat0_.home_address_location_id=addressloc1_.id left outer
join address_location addressloc2_ on
assetlocat0_.present_address_location_id=addressloc2_.id
where assetlocat0_.id='402881a6059e2dcb01059e3529220006';

I found that if I loaded the following dump into the test mysql
database then the above query was sufficient to case the problem:

-- MySQL dump 10.10
--
-- Host: localhost Database: test
-- ------------------------------------------------------
-- Server version 5.0.10-beta-debug

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,
SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `address_location`
--

DROP TABLE IF EXISTS `address_location`;
CREATE TABLE `address_location` (
`id` varchar(100) NOT NULL default '',
`city` varchar(100) default '',
`code` varchar(100) default '',
`country` varchar(100) default '',
`county` varchar(100) default '',
`street` varchar(100) default '',
`state` varchar(100) default '',
`postal_code` varchar(100) default '',
`name` varchar(100) default '',
`latitude` double default NULL,
`longitude` double default NULL,
`altitude` double default NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

--
-- Dumping data for table `address_location`
--


/*!40000 ALTER TABLE `address_location` DISABLE KEYS */;
LOCK TABLES `address_location` WRITE;
INSERT INTO `address_location` VALUES
('402881a6059c144101059c1957c20007',NULL,NULL,NULL,NULL,NULL ,NULL,NULL,N
ULL,0,0,0);
UNLOCK TABLES;
/*!40000 ALTER TABLE `address_location` ENABLE KEYS */;

--
-- Table structure for table `asset_location`
--

DROP TABLE IF EXISTS `asset_location`;
CREATE TABLE `asset_location` (
`id` varchar(100) NOT NULL default '',
`deployed_address_location_id` varchar(100) default '',
`home_address_location_id` varchar(100) default '',
`present_address_location_id` varchar(100) default '',
`next_destination_address_location_id` varchar(100) default '',
`arrival_date` datetime default '0000-00-00 00:00:00',
`departure_date` datetime default '0000-00-00 00:00:00',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

--
-- Dumping data for table `asset_location`
--


/*!40000 ALTER TABLE `asset_location` DISABLE KEYS */;
LOCK TABLES `asset_location` WRITE;
INSERT INTO `asset_location` VALUES
('402881a6059c144101059c1957c20006','',NULL,'402881a6059c144 101059c1957c
20007','','0000-00-00 00:00:00','0000-00-00 00:00:00');
UNLOCK TABLES;
/*!40000 ALTER TABLE `asset_location` ENABLE KEYS */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;




>Fix:
lines)>

None known.

>Submitter-Id:
>Originator: tredmond@cougaarsoftware.com
>Organization:
Cougaar Software
>MySQL support: none
>Synopsis:
>Severity: serious
>Priority: medium
>Category: mysql
>Class: sw-bug
>Release: mysql-5.0.10-beta (Source distribution)

>C compiler: powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026
(Apple Computer, Inc. build 4061)
>C++ compiler: powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026
(Apple Computer, Inc. build 4061)
>Environment:
System: Darwin Andromeda.local 8.1.0 Darwin Kernel Version 8.1.0: Tue
May 10 18:16:08 PDT 2005; root:xnu-792.1.5.obj~4/RELEASE_PPC Power
Macintosh powerpc

Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gcc /usr/bin/cc
GCC: Reading specs from /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/specs
Configured with: /private/var/tmp/gcc/gcc-4061.obj~8/src/configure --
disable-checking --prefix=/usr --mandir=/share/man --enable-
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^+.-]*$/
s/$/-4.0/ --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ --
build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --
target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.0 20041026 (Apple Computer, Inc. build 4061)
Compilation info: CC='gcc' CFLAGS='-O2' CXX='gcc' CXXFLAGS='-O2 -
felide-constructors -fno-exceptions -fno-rtti' LDFLAGS=''
ASFLAGS=''
LIBC:
lrwxr-xr-x 1 root wheel 15 May 22 16:59 /usr/lib/libc.dylib ->
libSystem.dylib
Configure command: ./configure '--prefix=/usr/local/mysql' '--with-
debug' '--with-extra-charsets=complex' 'CC=gcc' 'CFLAGS=-O2'
'CXXFLAGS=-O2 -felide-constructors -fno-exceptions -fno-rtti'
'CXX=gcc'


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

RE: mysql 14.12 Distrib 5.0.10-beta crashes on complex join query (similar to bug 12392 ?)

am 02.09.2005 17:37:33 von Valeriy Kravchuk

Hi,

I was able to repeat the crash you described on 5.0.10-beta-nt also. Even
attempt to get a plan for the query (explain ...) results in crash.

But I think we should wait for 5.0.12-beta version to be released
(http://bugs.mysql.com/bug.php?id=12392), because the patch as it is applied
to 5.0.10 sources may give incorrect results.

I'll try to repeat the bug you described on Linux and latest 5.0.x-BK build
on Sunday.

Best regards.
--
Valeriy Kravchuk, Support Engineer
MySQL AB, Kiev, Ukraine, www.mysql.com

Are you MySQL certified? www.mysql.com/certification


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org