Bug #41481 Buffer function never returns, cpu 100%, system locks up
Submitted: 15 Dec 2008 18:00 Modified: 17 Aug 2011 13:48
Reporter: John Powell Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: GIS Severity:S3 (Non-critical)
Version:mysql-5.1-wl1326 OS:Linux (Ubuntu 8.1)
Assigned to: Alexey Botchkov CPU Architecture:Any
Tags: buffer, gis

[15 Dec 2008 18:00] John Powell
Description:
Buffer function never returns. CPU goes to 100%, memory use 100%, system becomes totally unresponsive. The behavior is similar to that observed with bug #32100.

With simple queries like:
set @geom=geomfromtext('POINT(0 0)');
set @geom1=buffer(@geom,10);
select area(@geom1);
+-----------------+
| area(@geom1)    |
+-----------------+
| 314.02129486295 | 
+-----------------+
the function behaves fine. As soon as I try and do an update on real world data with multiple rows the problem becomes apparent.

How to repeat:
Using the slightly excessive proc from bug #32100 (as I currently can't create procs -- another bug).

DELIMITER $$

DROP PROCEDURE IF EXISTS `gml`.`testGeom`$$
CREATE DEFINER=`root`@`localhost` PROCEDURE `testGeom`(numGeoms int, circlePoints int)
BEGIN
	declare counter, circlecount int;
	declare g varchar(15000);
	
	declare x, y, width, cx, cy, radians real;
	declare line geometry;
	declare len int;
	set g='';
	
	set cy=0;set cx=0;

	drop table if exists coords;
	create table coords(geom geometry not null, spatial index (geom)); 
	
	set counter=0;
	set circlecount=0;
	set radians=2*PI()/circlePoints;	
	
	while  counter<numGeoms do
		set width=rand()*100;
		set cx=rand()*100;
		set cy=rand()*100;
		
		while circlecount<circlePoints do
			set x=cos(circleCount*radians)*width+cx;
			set y=sin(circleCount*radians)*width+cy;
			set g=concat(x, ' ', y, ', ',g);			
			set circlecount=circlecount+1;		
		end while;
		
		set len=length(g)-2;		
		set g=substring(g,1,len);		
		set g=concat('LINESTRING(',g,')');		
		
		insert into coords values(geomfromtext(g));
		
		set circlecount=0;
		set counter=counter+1;
		set g='';

	end while;
END$$

DELIMITER ;

mysql> call testGeom(1000,100);
msyql> alter table coords add column geomBuffered geometrycollection not null;
mysql> update coords set geomBuffered=buffer(geom, 10); 

At this point, system meltdown occurs.
[15 Dec 2008 21:51] John Powell
Apologies, I forgot to mention, this is from the bzr branch mysql-5.1-wl1326
[15 Dec 2008 22:19] Sveta Smirnova
Thank you for the report.

Verified as described.
[24 Dec 2008 18:13] 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/62310

2655 Alexey Botchkov	2008-12-24
      Bug#41481 Buffer function never returns, cpu 100%, system locks up 
          some cases were inproperly handled in the 'slicescan' alorithm
      
      modified:
        sql/gcalc_slicescan.cc
        sql/item_geofunc.cc
[7 Jul 2009 9:51] Lenz Grimmer
I've tried to verify the bug fix on a recent snapshot build from the wl1326 source tree (a windows binary taken off pushbuild, version 5.1.35-snapshot20090630).

Updating the table now crashes mysqld.exe with the following backtrace:

mysql> call testGeom(1000,100);
Query OK, 1 row affected, 1 warning (1.93 sec)

mysql> alter table coords add column geomBuffered geometrycollection not null;
Query OK, 1000 rows affected (0.13 sec)
Records: 1000  Duplicates: 0  Warnings: 0

mysql> update coords set geomBuffered=buffer(geom, 10);
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>

The server prints the following output:

090707 10:59:57 - mysqld got exception 0xc0000005 ;
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=8384512
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337716 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x1ad6de0
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...
0050BCFE    mysqld.exe!wkb_get_double()[spatial.cc:205]
0050C409    mysqld.exe!Gis_point::init_from_wkb()[spatial.cc:451]
0050CED7    mysqld.exe!Gis_polygon::priv_init_from_opresult()[spatial.cc:828]
0050E941    mysqld.exe!Gis_multi_polygon::init_from_opresult()[spatial.cc:1774]
005A31B6    mysqld.exe!String::realloc()[sql_string.cc:82]
0048E0A1    mysqld.exe!Item_func_buffer::val_str()[item_geofunc.cc:1149]
0044F268    mysqld.exe!Item::save_in_field()[item.cc:4893]
0052BBE7    mysqld.exe!fill_record()[sql_base.cc:8106]
0052BCA9    mysqld.exe!fill_record_n_invoke_before_triggers()[sql_base.cc:8151]
005B8587    mysqld.exe!mysql_update()[sql_update.cc:583]
00558628    mysqld.exe!mysql_execute_command()[sql_parse.cc:3028]
0055CB91    mysqld.exe!mysql_parse()[sql_parse.cc:5933]
0055D661    mysqld.exe!dispatch_command()[sql_parse.cc:1218]
0055E453    mysqld.exe!do_command()[sql_parse.cc:861]
005E0CB1    mysqld.exe!handle_one_connection()[sql_connect.cc:1115]
0064997B    mysqld.exe!pthread_start()[my_winthread.c:85]
0072D1C9    mysqld.exe!_callthreadstart()[thread.c:293]
024EE900
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 01B22B50=update coords set geomBuffered=buffer(geom, 10)
thd->thread_id=2
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
[7 Jul 2009 10:43] Lenz Grimmer
Reproducing the crash with a mysqld-debug.exe binary interestingly reveals less information, it seems:

090707 12:04:16 [Note] C:\mysql\bin\mysqld-debug.exe: ready for connections.
Version: '5.1.35-snapshot20090630-debug'  socket: ''  port: 3306  Source distrib
ution
090707 12:22:46 - mysqld got exception 0xc0000005 ;
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=8384512
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337714 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x1ffb828
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...
009E322A    mysqld-debug.exe!???
007A67CC    mysqld-debug.exe!???
007A7831    mysqld-debug.exe!???
004F8FDB    mysqld-debug.exe!???
0048AEAD    mysqld-debug.exe!???
0062D595    mysqld-debug.exe!???
0062D3D1    mysqld-debug.exe!???
0074928A    mysqld-debug.exe!???
00689CDB    mysqld-debug.exe!???
00691C71    mysqld-debug.exe!???
006860FE    mysqld-debug.exe!???
00685774    mysqld-debug.exe!???
0079D1C6    mysqld-debug.exe!???
00873E76    mysqld-debug.exe!???
009E8E53    mysqld-debug.exe!???
009E8DE9    mysqld-debug.exe!???
7C80B50B    kernel32.dll!GetModuleFileNameA()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 02049A48=update coords set geomBuffered=buffer(geom, 10)
thd->thread_id=2
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
[17 Aug 2011 13:48] Jon Stephens
Fixed in tree, doesn't seem to appear in a release, so no changelog entry needed. Closed.