mysql dies on simple select

Bug #381904 reported by Adam Golebiowski
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
PLD Linux
Fix Released
Undecided
Unassigned

Bug Description

[root@angua mysql]# service mysql stop
Stopping MySQL /var/lib/mysql service...............................................................................................................................[ DONE ]
[root@angua mysql]# rm /var/log/mysql/* /var/lib/mysql/mysqldb -rf
[root@angua mysql]# service mysql init
Initializing cluster /var/lib/mysql.................................................................................................................................
Installing MySQL system tables for /var/lib/mysql/mysqldb/db........................................................................................................[ DONE ]

PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL USERS!
This is done, after starting database, in the order shown,
with:

For 'mysql_sysadmin' (RELOAD and SHUTDOWN privileges):
echo "update mysql.user set password=password('newpassword') where user='mysql_sysadmin'; FLUSH PRIVILEGES;" | mysql -u mysql -S /var/lib/mysql/mysqldb/mysql.sock

For 'mysql' user (ALL privileges, DB admin):
echo "update mysql.user set password=password('newpassword') where user='mysql'; FLUSH PRIVILEGES;" | mysql -u mysql -S /var/lib/mysql/mysqldb/mysql.sock

NOTE: mysql_sysadmin password should be placed to /var/lib/mysql/mysqld.conf in
mysqladmin section. See the manual for more instructions.
(This user is used at logs rotation and server shutdown)

Filling help tables.................................................................................................................................................[ DONE ]
[root@angua mysql]# service mysql start
Starting MySQL /var/lib/mysql service...............................................................................................................................[ DONE ]
_sysadmin'; FLUSH PRIVILEGES;" | mysql -u mysql -S /var/lib/mysql/mysqldb/mysql.sock <
[root@angua mysql]# echo "update mysql.user set password=password('newpassword') where user='mysql'; FLUSH PRIVILEGES;" | mysql -u mysql -S /var/lib/mysql/mysqldb/mysql.sock
[root@angua mysql]# mysqladmin -u mysql --password=newpassword create poczta
[root@angua mysql]# echo "grant all privileges on poczta.* to poczta@localhost identified by 'poczta'; FLUSH PRIVILEGES;" | mysql -u mysql --password=mysql mysql
[root@angua mysql]# cat /tmp/poczta.dump
CREATE TABLE `exim_greylist` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `relay_ip` varchar(64) DEFAULT NULL,
  `from_domain` varchar(255) DEFAULT NULL,
  `block_expires` datetime NOT NULL,
  `record_expires` datetime NOT NULL,
  `origin_type` enum('MANUAL','AUTO') NOT NULL DEFAULT 'AUTO',
  `create_time` datetime NOT NULL,
  PRIMARY KEY (`id`)
);

CREATE TABLE `mailboxes` (
  `domain` varchar(255) NOT NULL DEFAULT '',
  `username` varchar(255) NOT NULL DEFAULT '',
  `passwd` varchar(255) NOT NULL DEFAULT '',
  `alias` varchar(255) NOT NULL DEFAULT '',
  `remove_spam` tinyint(4) NOT NULL DEFAULT '0',
  `move_to_spam_folder` tinyint(4) NOT NULL DEFAULT '0',
  `do_not_mark_spam` tinyint(4) NOT NULL DEFAULT '0'
);

INSERT INTO `mailboxes` VALUES ('example.com','adamg','9dd4e461268c8034f5c8564e155c67a6','',0,0,0);
[root@angua mysql]# mysql -u poczta --password=poczta poczta < /tmp/poczta.dump
[root@angua mysql]# echo 'SELECT * FROM mailboxes;' | mysql -u poczta --password=poczta poczta
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query
[root@angua mysql]# cat /var/log/mysql/mysqld.log
InnoDB: The first specified data file /var/lib/mysql/mysqldb/db/ibdata1 did not exist:
InnoDB: a new database to be created!
090530 17:03:17 InnoDB: Setting file /var/lib/mysql/mysqldb/db/ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
090530 17:03:17 InnoDB: Log file /var/lib/mysql/mysqldb/db/ib_logfile0 did not exist: new to be created
InnoDB: Setting log file /var/lib/mysql/mysqldb/db/ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
090530 17:03:17 InnoDB: Log file /var/lib/mysql/mysqldb/db/ib_logfile1 did not exist: new to be created
InnoDB: Setting log file /var/lib/mysql/mysqldb/db/ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
090530 17:03:17 InnoDB: Started; log sequence number 0 0
090530 17:03:17 InnoDB: Starting shutdown...
090530 17:03:19 InnoDB: Shutdown completed; log sequence number 0 46409
090530 17:03:19 [Warning] Forcing shutdown of 1 plugins
090530 17:03:19 InnoDB: Started; log sequence number 0 46409
090530 17:03:19 InnoDB: Starting shutdown...
090530 17:03:20 InnoDB: Shutdown completed; log sequence number 0 46409
090530 17:03:20 [Warning] Forcing shutdown of 1 plugins
090530 17:03:24 InnoDB: Started; log sequence number 0 46409
090530 17:03:24 [Note] Event Scheduler: Loaded 0 events
090530 17:03:24 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.34-log' socket: '/var/lib/mysql/mysqldb/mysql.sock' port: 0 PLD Linux Distribution MySQL RPM
090530 17:05:47 - 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=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 = 337743 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x8b1a0b8
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...
stack_bottom = 0xb489936c thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29) [0x8478b3f]
/usr/sbin/mysqld(handle_segfault+0x4bd) [0x81cf450]
[0xb80a4400]
/usr/sbin/mysqld(QUERY_PROFILE::new_status(char const*, char const*, char const*, unsigned int)+0x68) [0x825151a]
/usr/sbin/mysqld(PROFILING::status_change(char const*, char const*, char const*, unsigned int)+0x51) [0x82515dd]
/usr/sbin/mysqld(set_thd_proc_info+0x4a) [0x81be46b]
/usr/sbin/mysqld(check_access(THD*, unsigned long, char const*, unsigned long*, bool, bool, bool)+0x92) [0x81d8382]
/usr/sbin/mysqld(check_table_access(THD*, unsigned long, TABLE_LIST*, unsigned int, bool)+0x206) [0x81d8d2c]
/usr/sbin/mysqld(mysql_execute_command(THD*)+0x59e) [0x81dc75b]
/usr/sbin/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0x2f1) [0x81e3cbf]
/usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xdcc) [0x81e4f7e]
/usr/sbin/mysqld(do_command(THD*)+0xf5) [0x81e589d]
/usr/sbin/mysqld(handle_one_connection+0x32a) [0x81d6003]
/lib/libpthread.so.0 [0xb8088522]
/lib/libpthread.so.0 [0xb808843d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8b6a360 = SELECT * FROM mailboxes
thd->thread_id=6
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.
[root@angua mysql]#

Revision history for this message
Elan Ruusamäe (glen666) wrote :

rpm package version/arch and your distro version?

Revision history for this message
Adam Golebiowski (adamg) wrote :

mysql-5.1.34-4 (also happens on 5.1.34-1), fresh th-i686 installation based on yesterday (20090530) th-main tree (with mysql-5.1.34-4 from th-test).

What's important is that mysql does not die when I connect and execute queries as 'mysql' user.

I also filled bug report in mysql's BTS: http://bugs.mysql.com/bug.php?id=45205

Revision history for this message
Adam Golebiowski (adamg) wrote :

fixed with 5.1.35-1

Changed in pld-linux:
status: New → Fix Committed
Revision history for this message
Adam Golebiowski (adamg) wrote :

something's heavily broken on our builders, mysql-5.1.35-1 built locally works fine, the one built on builders (th-i686 at least) crashes as described.

Changed in pld-linux:
status: Fix Committed → New
Revision history for this message
Adam Golebiowski (adamg) wrote :

a simplified case to trigger a crash:

[root@ankh-th ~]# mysql -u test -p test
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.35 PLD Linux Distribution MySQL RPM

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> create table x (a int);
Query OK, 0 rows affected (0.00 sec)

mysql> select 1 from x;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> Bye
[root@ankh-th ~]#

Revision history for this message
Marcin Krol (hawq) wrote :

Just to let you know. On Titanium it works, both i686 and x86_64 version, built by builders of course.

mysql-5.1.34-1

I'll test 5.1.35 soon.

Revision history for this message
Marcin Krol (hawq) wrote :

mysql-5.1.35-1 built on Titanium builders works correctly. I've just tested i686 and x86_64 with procedure from this thread.

Revision history for this message
Arkadiusz Miśkiewicz (arekm) wrote :

th-x86_64 works, th-i686 breaks. Test done with:

rm -rf /var/lib/mysql/*
service mysql init
service mysql start
mysql -u mysql
CREATE DATABASE lms CHARACTER SET utf8 COLLATE utf8_polish_ci;
GRANT USAGE ON lms.* TO lms@localhost;
GRANT ALL ON lms.* TO lms@localhost IDENTIFIED BY 'twoje_hasło';
QUIT
mysql -u lms -p lms
create table x (a int);
select 1 from x;

Revision history for this message
redguy (mateusz-kijowski) wrote :

I tried to run 5.1.34-1 from repos and 5.1.34-1 built locally 5.1.35-2 and 5.1.33-2 and none of these worked.
I have th-i686 installed.

Perhaps this is not related to mysql at all?

Revision history for this message
Arkadiusz Miśkiewicz (arekm) wrote :

5.1.36-4 seems to be working (the "fix" was to update opt flags to match mysql configure script).

Note that more testing and confirmation is needed from people reporting here.

Revision history for this message
Adam Golebiowski (adamg) wrote :

Release 4 works for me on two machines where earlier versions were crashing

Changed in pld-linux:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.