Bug #28364 Mysql server crashes during a query
Submitted: 10 May 2007 23:36 Modified: 11 Jun 2007 13:38
Reporter: Lyuben Stoev Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: MyISAM storage engine Severity:S1 (Critical)
Version:5.0.33, 5.0.41 OS:Linux (Gentoo)
Assigned to: Assigned Account CPU Architecture:Any
Tags: distinct, nested SELECT, SELECT

[10 May 2007 23:36] Lyuben Stoev
Description:
1. Tested with manual compiled version on gentoo (glibc 2.5 - CFLAGS="-O2 -march=pentium4 -pipe") with: 
./configure --prefix=/usr/local/mysql --enable-assembler --without-debug --without-docs --without-bench --with-charset=cp1251 --with-extra-charsets=all --enable-thread-safe-client --with-unix-socket-path=/tmp/mysql.sock --with-mysqld-user=mysql

During this query: SELECT DISTINCT Feed.FeedID , Feed.Url , (SELECT FeedMessage.ItemCode FROM FeedMessage WHERE FeedMessage.FeedID=Feed.FeedID ORDER BY FeedMessage.FeedMessageID DESC LIMIT 1) AS LastFeedMessageItemCode FROM Feed  WHERE Feed.FeedID IN (3196,3191,3192,3194,3225,3193,3249,3132,3171,3176,3131,3154,3264,3133,3147)  LIMIT 0, 100
The server crashes, and restarts itself.

Here is the whole output:

070511  0:45:35 - mysqld got signal 11;
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=402653184
read_buffer_size=131072
max_used_connections=6
max_connections=400
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1673212 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8d85cc0
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=0xaf491d58, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81761f8
0x814f03c
0x823a2a6
0x81d452a
0x81e1c76
0x8145354
0x8144734
0x814497f
0x80eee5f
0x8168ba9
0x81c68eb
0x81d0b8d
0x81d0c3f
0x81d1055
0x81e1d54
0x81e40b4
0x81e49df
0x818ea8f
0x8195c09
0x8196150
0x81977cb
0x8198349
0xb7f072c1
0xb7d4f17e
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 0x8d8f1c8 = SELECT DISTINCT Feed.FeedID , Feed.Url , (SELECT FeedMessage.ItemCode FROM FeedMessage WHERE FeedMessage.FeedID=Feed.FeedID ORDER BY FeedMessage.FeedMessageID DESC LIMIT 1) AS LastFeedMessageItemCode FROM Feed  WHERE Feed.FeedID IN (3196,3191,3192,3194,3225,3193,3249,3132,3171,3176,3131,3154,3264,3133,3147)  LIMIT 0, 100
thd->thread_id=114
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.

Number of processes running now: 0
070511 00:45:35  mysqld restarted
070511  0:45:35  InnoDB: Started; log sequence number 0 698697478
070511  0:45:35 [Note] /usr/local/mysql/libexec/mysqld: ready for connections.
Version: '5.0.41-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution

2. Tested on the same gantoo machine with Linux (x86, glibc-2.2, "standard" is static) same results

How to repeat:
Here is the query:
SELECT DISTINCT Feed.FeedID , Feed.Url , (SELECT FeedMessage.ItemCode FROM FeedMessage WHERE FeedMessage.FeedID=Feed.FeedID ORDER BY FeedMessage.FeedMessageID DESC LIMIT 1) AS LastFeedMessageItemCode FROM Feed  WHERE Feed.FeedID IN (3196,3191,3192,3194,3225,3193,3249,3132,3171,3176,3131,3154,3264,3133,3147)  LIMIT 0, 100;

The two tables:

CREATE TABLE `FeedMessage` (
  `FeedMessageID` int(10) unsigned NOT NULL auto_increment,
  `Code` varchar(255) default NULL,
  `ItemCode` varchar(80) default NULL,
  `Name` varchar(255) default NULL,
  `Description` text,
  `Url` varchar(1000) default NULL,
  `FeedID` int(6) unsigned NOT NULL,
  `Date` int(11) unsigned default NULL,
  `PublishDate` int(10) unsigned default NULL,
  `Author` varchar(255) default NULL,
  `CommentsCount` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`FeedMessageID`),
  UNIQUE KEY `1` (`Code`),
  KEY `3` (`FeedID`)
) ENGINE=MyISAM AUTO_INCREMENT=36550 DEFAULT CHARSET=utf8 DELAY_KEY_WRITE=1 |

CREATE TABLE `Feed` (
  `FeedID` int(10) unsigned NOT NULL auto_increment,
  `Code` varchar(80) default NULL,
  `Url` varchar(255) default NULL,
  `Link` varchar(255) default NULL,
  `Name` varchar(255) default NULL,
  `UserID` int(11) default NULL,
  `AuthorUsername` varchar(255) default NULL,
  `IsProcessed` int(10) unsigned NOT NULL default '0',
  `Date` int(11) default NULL,
  `Description` text,
  `SourceImageSrc` varchar(255) default NULL,
  `SourceImageTitle` varchar(255) default NULL,
  `SourceImageLink` varchar(255) default NULL,
  `TagsReview` varchar(255) default NULL,
  `InFavouritesCount` int(10) unsigned NOT NULL default '0',
  `CommentsCount` int(10) unsigned NOT NULL default '0',
  `FeedMessagesCount` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`FeedID`),
  KEY `3` (`Date`),
  KEY `4` (`InFavouritesCount`)
) ENGINE=MyISAM AUTO_INCREMENT=3346 DEFAULT CHARSET=utf8

Suggested fix:
no suggested fix, Just a workaround use 5.0.27 - no such crash!
[11 May 2007 13:38] Sveta Smirnova
Thank you for the report.

I can not repeat described behaviour with current sources and sample data.

Please provide output of SHOW TABLE STATUS for both tables in the query. Also please upload error log file.
[11 Jun 2007 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".