Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 452824 - mysql-server crash permanently
Summary: mysql-server crash permanently
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mysql
Version: 5.2
Hardware: All
OS: Linux
high
urgent
Target Milestone: rc
: ---
Assignee: Tom Lane
QA Contact:
URL: http://bugs.mysql.com/bug.php?id=37626
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-25 11:31 UTC by Levente Farkas
Modified: 2013-07-03 03:18 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-02 09:45:37 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1289 normal SHIPPED_LIVE Moderate: mysql security and bug fix update 2009-09-01 13:32:14 UTC

Description Levente Farkas 2008-06-25 11:31:29 UTC
Description of problem:
fter we upgrade ot rhel-5.2 which contains mysql-5.0.45 we permanently (every
minutes)
got this error in the log file:
----------------------------------------------
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=268435456
read_buffer_size=1044480
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 = 466543 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x9c1c4a0
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=0xa0161f98, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8187393
(nil)
0x828e2b3
0x828f920
0x828f7ea
0x81c8ec3
0x81a06b9
0x81a3e90
0x81a4473
0x81a58b7
0x81a6487
0x88246b
0x413dbe
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.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 0x9c53b20 = select ID, NAME, TYPE, asText(POLYLINE) from
geo_all_road r
where MBRIntersects(GeomFromText('Polygon((19.029111 47.472561,19.029561
47.472561,19.029561 47.472111,19.029111 47.47211
1,19.029111 47.472561))'), r.POLYLINE)
thd->thread_id=1
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
----------------------------------------------
after using http://dev.mysql.com/doc/mysql/en/using-stack-trace.html i've got
----------------------------------------------
0x8187393 handle_segfault + 755
(nil)
0x828e2b3 st_select_lex_unit::prepare(THD*, select_result*, unsigned long) + 2787
0x828f920 mysql_derived_prepare(THD*, st_lex*, st_table_list*) + 224
0x828f7ea mysql_handle_derived(st_lex*, bool (*)(THD*, st_lex*, st_table_list*))
+ 90
0x81c8ec3 open_and_lock_tables(THD*, st_table_list*) + 131
0x81a06b9 mysql_execute_command(THD*) + 15017
0x81a3e90 mysql_parse(THD*, char const*, unsigned int, char const**) + 368
0x81a4473 dispatch_command(enum_server_command, THD*, char*, unsigned int) + 1251
0x81a58b7 do_command(THD*) + 167
0x81a6487 handle_one_connection + 2695
0x15546b (?)
0x2e3dbe (?)
----------------------------------------------
what can be the reason?
we just start mysql, and use Django and httpd.

Comment 1 Tom Lane 2008-06-25 13:04:37 UTC
Looks like you've already filed this upstream, which is really the correct place for it.  I don't see anything 
else in their bugzilla that looks like they might have recently fixed such a bug, so that knee-jerk advice 
about updating to a (slightly) newer version doesn't sound helpful at all.  What you'll need to do is provide 
them with enough info to reproduce the problem --- the whole query, the table definitions, and perhaps 
some test data too.

Comment 2 Levente Farkas 2008-06-25 20:41:06 UTC
mysql verify in the upstream bugreport that it's a bug in 5.0.45 which is fixed
in 52. would it be possible to somehow patch 45?

Comment 3 Tom Lane 2008-06-25 23:22:54 UTC
Not with no patch provided, and 5.0.52 not released ...

Comment 4 Levente Farkas 2008-07-31 15:17:35 UTC
yes but with the current rh's mysql the server repeatedly crash (more than once
a day) while if i downgrade to rhel-5.1's mysql-server the problem disappear. so
the current version is worse then the previous, imho rh should have to try to
fix it or downgrade it's mysql-server to a previous version.

Comment 5 Levente Farkas 2008-10-07 15:39:36 UTC
there are much newer mysql version and those version fix this bug. it'd be useful to upgade to newer version or at least backport their fix to the current rhel-5's mysql.

Comment 6 Levente Farkas 2008-10-23 20:58:07 UTC
any progress?

Comment 10 Karel Volný 2009-05-28 09:27:20 UTC
please, could you add the exact steps how to reproduce the problem?

- I've tried to refine it from the upstream bug report but had no success to reproduce the crash

my try:

1. install mysql-5.0.45-7.el5
2. service mysqld start
3. create tables - see below
4. tail -f /var/log/mysqld.log

none of the supported architectures experienced a crash


SQL code used to create the tables:

create database bz452824;
use bz452824;

CREATE TABLE `geo_road_custom` (
  `ID` int(11) NOT NULL,
  `NAME` varchar(50) default NULL,
  `TYPE` varchar(20) default NULL,
  `POLYLINE` geometry NOT NULL,
  PRIMARY KEY  (`ID`),
  UNIQUE KEY `ID` (`ID`),
  SPATIAL KEY `POLYLINE` (`POLYLINE`(32))
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL
SECURITY DEFINER VIEW `geo_road_custom_ordered` AS select `r`.`ID` AS `ID`,`r`.`NAME` AS
`NAME`,`r`.`TYPE` AS `TYPE`,`r`.`POLYLINE` AS `POLYLINE` from `geo_road_custom` `r` order
by `r`.`TYPE` desc,`r`.`POLYLINE` desc;

CREATE TABLE `geo_road_base` (
  `ID` int(11) NOT NULL,
  `NAME` varchar(50) default NULL,
  `TYPE` varchar(20) default NULL,
  `POLYLINE` geometry NOT NULL,
  PRIMARY KEY  (`ID`),
  UNIQUE KEY `ID` (`ID`),
  SPATIAL KEY `POLYLINE` (`POLYLINE`(32))
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER
VIEW `geo_road` AS select `r`.`ID` AS `ID`,`r`.`NAME` AS `NAME`,`r`.`TYPE` AS
`TYPE`,`r`.`POLYLINE` AS `POLYLINE` from `geo_road_base` `r` where ((`r`.`TYPE` =
_utf8'Highway') or (`r`.`TYPE` = _utf8'Freeway')) order by `r`.`TYPE` desc,`r`.`POLYLINE`
desc;

CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY
DEFINER VIEW `geo_all_road` AS select `rc`.`ID` AS `ID`,`rc`.`NAME` AS `NAME`,`rc`.`TYPE`
AS `TYPE`,`rc`.`POLYLINE` AS `POLYLINE` from `geo_road_custom_ordered` `rc` union select
`r`.`ID` AS `ID`,`r`.`NAME` AS `NAME`,`r`.`TYPE` AS `TYPE`,`r`.`POLYLINE` AS `POLYLINE`
from `geo_road` `r`;

Comment 12 Levente Farkas 2009-06-16 17:19:04 UTC
the real problem is that the datebase is google maps's database which is commercial so i can't send the whole database to you. that was the reason why i send the table format to the upstream bugreport where they confirm the problem. i can send you the same set of table format, but not too much more. anyway it was on both i386 and x86_64 and mysql-5.0.45 if you simple upgrade mysql to at least  mysql-5.0.52 than it solves the problem.

Comment 13 errata-xmlrpc 2009-09-02 09:45:37 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1289.html


Note You need to log in before you can comment on or make changes to this bug.