| Bug #33705 | Order by xxxx DESC is causing MySQL server to Crash (signal 11) | ||
|---|---|---|---|
| Submitted: | 5 Jan 2008 17:25 | Modified: | 2 Apr 2008 9:01 |
| Reporter: | FnG Lambik | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server | Severity: | S2 (Serious) |
| Version: | 5.0.45 | OS: | Linux (openSuSE 10.3 64-bit) |
| Assigned to: | CPU Architecture: | Any | |
[5 Jan 2008 17:25]
FnG Lambik
[5 Jan 2008 17:26]
FnG Lambik
***** Crash log of the GameStats server ************************** Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 SUSE MySQL RPM 080105 17:26:50 - mysqld got signal 6; 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=16777216 read_buffer_size=258048 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 = 92783 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x21ccc50 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=0x44088fe0, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) New value of fp=0x21ccc50 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 0x2205d50 = SELECT pnum,plr_name,plr_bot,plr_frags,plr_score,plr_kills,plr_deaths,plr_suicides,plr_matches,plr_time,plr_wins,plr_teamwins FROM ut_players USE INDEX (plr_sscore) WHERE plr_bot=0 ORDER BY plr_score DESC,plr_frags DESC,plr_deaths DESC LIMIT 0,50 thd->thread_id=16 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. pure virtual method called terminate called without an active exception Number of processes running now: 1 mysqld process hanging, pid 2643 - killed 080105 17:26:51 mysqld restarted 080105 17:26:51 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 080105 17:26:51 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 080105 17:26:51 mysqld ended 080105 17:27:11 mysqld started 080105 17:27:11 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 080105 17:27:11 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 080105 17:27:11 InnoDB: Started; log sequence number 0 43665 080105 17:27:11 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 SUSE MySQL RPM
[5 Jan 2008 17:31]
FnG Lambik
**** Crash log of the phpBB3 Forum ****************** *** first attempt to "view new posts" ******************** Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3308 SUSE MySQL RPM 080105 16:35:24 - mysqld got signal 7; 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=8388608 read_buffer_size=8384512 max_used_connections=2 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 = 4103791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x19d2380 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=0x44088fe0, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) New value of fp=0x19d2380 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 0x1a8b0c0 = SELECT t.topic_id FROM lambik_topics t WHERE t.topic_last_post_time > 1197648674 AND t.topic_moved_id = 0 ORDER BY t.topic_last_post_time DESC LIMIT 1001 thd->thread_id=6 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: 1 mysqld process hanging, pid 530 - killed 080105 16:35:24 mysqld restarted 080105 16:35:24 [Warning] Changed limits: max_open_files: 65535 max_connections: 100 table_cache: 32712 080105 16:35:24 InnoDB: Started; log sequence number 0 43665 080105 16:35:24 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3308 SUSE MySQL RPM **** This is after the second attempt to "view new posts" ********************* 080105 16:52:16 - 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=8388608 read_buffer_size=8384512 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 = 4103791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x19d2380 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=0x44088fe0, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) New value of fp=0x19d2380 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 (nil) is invalid pointer thd->thread_id=125 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. pure virtual method called terminate called without an active exception Fatal signal 6 while backtracing pure virtual method called terminate called recursively Number of processes running now: 1 mysqld process hanging, pid 752 - killed 080105 16:52:48 mysqld restarted 080105 16:52:48 [Warning] Changed limits: max_open_files: 65535 max_connections: 100 table_cache: 32712 080105 16:52:48 InnoDB: Started; log sequence number 0 43665 080105 16:52:48 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3308 SUSE MySQL RPM
[5 Jan 2008 21:37]
Valeriy Kravchuk
Thank you for a problem report. Please, try to repeat with a newer version, 5.0.51 at least, and inform about the results.
[8 Jan 2008 20:00]
FnG Lambik
Upgraded to 5.0.51 as you've requested, but I experience the same problem.
I used the following repository :
http://download.opensuse.org/repositories/server:/database/openSUSE_10.3/
Please find below the log output and http output.
PS:
If you additionaly request to update to a newer version(newer then 5.0.51), could you please help finding a proper repository for me ?
As my knowledge to configure/make/make install is very limited, not knowing which parameters I should add to the configure command.
MySQL Log :
***************************************************************************
Version: '5.0.51' socket: '/var/lib/mysql/mysql.sock' port: 3308 SUSE MySQL RPM
080108 20:54:45 - 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=8388608
read_buffer_size=8384512
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 = 4103791 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x19df700
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=0x44088fe0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x19df700 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 0x1a34f40 = SELECT t.topic_id
FROM lambik_topics t
WHERE t.topic_last_post_time > 1199555404
AND t.topic_moved_id = 0
ORDER BY t.topic_last_post_time DESC
LIMIT 1001
thd->thread_id=4
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: 2
mysqld process hanging, pid 18954 - killed
mysqld process hanging, pid 18948 - killed
080108 20:54:45 mysqld restarted
080108 20:54:45 [Warning] Changed limits: max_open_files: 65535 max_connections: 100 table_cache: 32712
080108 20:54:46 InnoDB: Started; log sequence number 0 43665
080108 20:54:46 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.51' socket: '/var/lib/mysql/mysql.sock' port: 3308 SUSE MySQL RPM
***************************************************************************
Web Output :
***************************************************************************
SQL ERROR [ mysqli ]
Lost connection to MySQL server during query [2013]
SQL
SELECT t.topic_id FROM lambik_topics t WHERE t.topic_last_post_time > 1199555404 AND t.topic_moved_id = 0 ORDER BY t.topic_last_post_time DESC LIMIT 1001
[10 Jan 2008 12:36]
Heikki Tuuri
Hi! Please print: EXPLAIN SELECT pnum,plr_name,plr_bot,plr_frags,plr_score,plr_kills,plr_deaths,plr_suicides,plr_matches,pl r_time,plr_wins,plr_teamwins FROM ut_players USE INDEX (plr_sscore) WHERE plr_bot=0 ORDER BY plr_score DESC,plr_frags DESC,plr_deaths DESC LIMIT 0,50 and SHOW CREATE TABLE ut_players. Regards, Heikki
[10 Jan 2008 17:57]
Georgi Kolev
Hi. I have the same problem. Yesterday I upgraded my server to OpenSuse 10.3 x86_64, MySql 5.0.45(from the DVD rpm). I noticed that MySQL often restarts and examined the logs. This is quote from the logs: --------------------------- 080110 19:34:51 - mysqld got signal 7; 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. thd=0x19ce410 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=0x44088fe0, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) New value of fp=0x19ce410 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 0x1a0c9e0 = SELECT * FROM zsmf_messages AS m WHERE m.ID_MSG < 23062 ORDER BY m.ID_MSG DESC LIMIT 1 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. Number of processes running now: 0 080110 19:34:51 mysqld restarted 080110 19:34:51 InnoDB: Started; log sequence number 0 1797248822 080110 19:34:51 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 SUSE MySQL RPM ---------- This query is executed in SMF forum. I stop all web servers and run the query by hand and it produced the same crash. The same database and software before upgrade was running on FC6 32bit, Mysql 5.0.27-1 and everything was fine.
[11 Jan 2008 0:43]
Georgi Kolev
I tried downgrading to 5.0.26 from RPM, tried compiling from source, tried precompiled no-rpm binaries with the Intel compiler... no chance :( The same error. I noticed that if we remove one of the clauses (WHERE m.ID_MSG < 23062, ORDER BY m.ID_MSG DESC, or the LIMIT) - the query passes. It also passes if i give a limit that is above the number of rows the query returns. EXPLAIN the query gives me the same crash. At the end I installed the 32-bit version of Mysql and for now everything is ok.
[11 Jan 2008 1:38]
Georgi Kolev
And I dont't know why this bug is categorized az InnoDB? All my tables are MyISAM and I compiled --without-innodb option. Some info about my server: Suse 10.3 x86_64 fresh installed from distributed DVD, without any updates; using default my.cnf uname -a Linux server 2.6.22.5-31-default #1 SMP 2007/09/21 22:29:00 UTC x86_64 x86_64 x86_64 GNU/Linux CPU: Intel P-D 2.8GHz HDD: 120GB SATA AHCI Filesystem: ext3
[11 Jan 2008 9:27]
MySQL Verification Team
The InnoDB category is because the original reporter filed it as InnoDB.
[11 Jan 2008 18:35]
Heikki Tuuri
This is not an InnoDB bug, as this appears also with MyISAM tables. Anyway, Georgi, please answer the questions I asked above from the original reporter.
[11 Jan 2008 19:43]
Georgi Kolev
What do you have asked? If it si about to print those queries - I don't have such table 'ut_players'.
[11 Jan 2008 20:19]
Marko Mäkelä
Georgi, I believe that Heikki accidentally copied the wrong SELECT statement (perhaps from a different bug report) to his question. He simply would like to see the query plan for the SELECT that causes the crash, and the table layout of the participating tables (the ones in the FROM list of the SELECT). So, please run EXPLAIN SELECT ... of the SELECT ... statement that causes the crash. And please run SHOW CREATE TABLE for each table in the FROM list of the SELECT statement. This information might allow someone to make an educated guess what is going wrong. Also a stack trace (when running mysqld inside a debugger) would be very useful.
[14 Jan 2008 18:19]
FnG Lambik
Hello, Sorry for my late response Heikki, The command : EXPLAIN SELECT ..... ********************************************************** Failed to execute SQL : SQL EXPLAIN SELECT pnum,plr_name,plr_bot,plr_frags,plr_score,plr_kills,plr_deaths,plr_suicides,plr_matches,plr_time,plr_wins,plr_teamwins FROM ut_players USE INDEX (plr_sscore) WHERE plr_bot=0 ORDER BY plr_score DESC,plr_frags DESC,plr_deaths DESC LIMIT 0,50 failed : Lost connection to MySQL server during query When I remove the 'DESC' : ********************************************************* mysql> EXPLAIN SELECT pnum,plr_name,plr_bot,plr_frags,plr_score,plr_kills,plr_deaths,plr_suicides,plr_matches,plr_time,plr_wins,plr_teamwins FROM ut_players USE INDEX (plr_sscore) WHERE plr_bot=0 ORDER BY plr_score ,plr_frags ,plr_deaths LIMIT 0,50; +----+-------------+------------+-------+---------------+------------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+-------+---------------+------------+---------+------+------+-------------+ | 1 | SIMPLE | ut_players | range | plr_sscore | plr_sscore | 1 | NULL | 2086 | Using where | +----+-------------+------------+-------+---------------+------------+---------+------+------+-------------+ 1 row in set (0.00 sec) When I remove the LIMIT 0,50 **************************************************** EXPLAIN SELECT pnum,plr_name,plr_bot,plr_frags,plr_score,plr_kills,plr_deaths,plr_suicides,plr_matches,plr_time,plr_wins,plr_teamwins FROM ut_players USE INDEX (plr_sscore) WHERE plr_bot=0 ORDER BY plr_score DESC ,plr_frags DESC,plr_deaths DESC; +----+-------------+------------+------+---------------+------+---------+------+------+-----------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+------+---------------+------+---------+------+------+-----------------------------+ | 1 | SIMPLE | ut_players | ALL | plr_sscore | NULL | NULL | NULL | 1566 | Using where; Using filesort | +----+-------------+------------+------+---------------+------+---------+------+------+-----------------------------+ 1 row in set (0.00 sec) Show Create Table ut_player **************************************************** ut_players Create Table: CREATE TABLE `ut_players` ( `pnum` mediumint(8) unsigned NOT NULL auto_increment, `plr_name` varchar(61) NOT NULL default '', `plr_bot` tinyint(3) unsigned NOT NULL default '0', `plr_frags` mediumint(9) NOT NULL default '0', `plr_score` int(10) NOT NULL default '0', `plr_kills` mediumint(8) unsigned NOT NULL default '0', `plr_deaths` mediumint(8) unsigned NOT NULL default '0', `plr_suicides` mediumint(8) unsigned NOT NULL default '0', `plr_headshots` mediumint(8) unsigned NOT NULL default '0', `plr_firstblood` mediumint(8) unsigned NOT NULL default '0', `plr_transgib` mediumint(8) unsigned NOT NULL default '0', `plr_headhunter` mediumint(8) unsigned NOT NULL default '0', `plr_flakmonkey` mediumint(8) unsigned NOT NULL default '0', `plr_combowhore` mediumint(8) unsigned NOT NULL default '0', `plr_roadrampage` mediumint(8) unsigned NOT NULL default '0', `plr_carjack` mediumint(8) unsigned NOT NULL default '0', `plr_roadkills` mediumint(8) unsigned NOT NULL default '0', `plr_user` varchar(35) NOT NULL default '', `plr_id` varchar(32) NOT NULL default '', `plr_key` varchar(32) NOT NULL default '', `plr_ip` varchar(21) NOT NULL default '', `plr_netspeed` mediumint(8) unsigned NOT NULL default '0', `plr_rpg` tinyint(1) unsigned NOT NULL default '0', `plr_matches` mediumint(8) unsigned NOT NULL default '0', `plr_time` bigint(19) unsigned NOT NULL default '0', `plr_fph` float NOT NULL default '0', `plr_sph` float NOT NULL default '0', `plr_eff` float NOT NULL default '0', `plr_wins` mediumint(8) unsigned NOT NULL default '0', `plr_teamwins` mediumint(8) unsigned NOT NULL default '0', `plr_losses` mediumint(8) unsigned NOT NULL default '0', `plr_multi1` mediumint(8) unsigned NOT NULL default '0', `plr_multi2` mediumint(8) unsigned NOT NULL default '0', `plr_multi3` mediumint(8) unsigned NOT NULL default '0', `plr_multi4` mediumint(8) unsigned NOT NULL default '0', `plr_multi5` mediumint(8) unsigned NOT NULL default '0', `plr_multi6` mediumint(8) unsigned NOT NULL default '0', `plr_multi7` mediumint(8) unsigned NOT NULL default '0', `plr_spree1` mediumint(8) unsigned NOT NULL default '0', `plr_spreet1` int(10) unsigned NOT NULL default '0', `plr_spreek1` mediumint(8) unsigned NOT NULL default '0', `plr_spree2` mediumint(8) unsigned NOT NULL default '0', `plr_spreet2` int(10) unsigned NOT NULL default '0', `plr_spreek2` mediumint(8) unsigned NOT NULL default '0', `plr_spree3` mediumint(8) unsigned NOT NULL default '0', `plr_spreet3` int(10) unsigned NOT NULL default '0', `plr_spreek3` mediumint(8) unsigned NOT NULL default '0', `plr_spree4` mediumint(8) unsigned NOT NULL default '0', `plr_spreet4` int(10) unsigned NOT NULL default '0', `plr_spreek4` mediumint(8) unsigned NOT NULL default '0', `plr_spree5` mediumint(8) unsigned NOT NULL default '0', `plr_spreet5` int(10) unsigned NOT NULL default '0', `plr_spreek5` mediumint(8) unsigned NOT NULL default '0', `plr_spree6` mediumint(8) unsigned NOT NULL default '0', `plr_spreet6` int(10) unsigned NOT NULL default '0', `plr_spreek6` mediumint(8) unsigned NOT NULL default '0', `plr_combo1` mediumint(8) unsigned NOT NULL default '0', `plr_combo2` mediumint(8) unsigned NOT NULL default '0', `plr_combo3` mediumint(8) unsigned NOT NULL default '0', `plr_combo4` mediumint(8) unsigned NOT NULL default '0', `plr_flagcapture` mediumint(8) unsigned NOT NULL default '0', `plr_flagreturn` mediumint(8) unsigned NOT NULL default '0', `plr_flagkill` mediumint(8) unsigned NOT NULL default '0', `plr_cpcapture` mediumint(8) unsigned NOT NULL default '0', `plr_bombcarried` mediumint(8) unsigned NOT NULL default '0', `plr_bombtossed` mediumint(8) unsigned NOT NULL default '0', `plr_bombkill` mediumint(8) unsigned NOT NULL default '0', `plr_nodeconstructed` mediumint(8) unsigned NOT NULL default '0', `plr_nodedestroyed` mediumint(8) unsigned NOT NULL default '0', `plr_nodeconstdestroyed` mediumint(8) unsigned NOT NULL default '0', UNIQUE KEY `pnum` (`pnum`), KEY `plr_name` (`plr_name`), KEY `plr_bot` (`plr_bot`,`plr_name`), KEY `plr_usrid` (`plr_user`,`plr_id`), KEY `plr_sscore` (`plr_bot`,`plr_score`,`plr_frags`,`plr_deaths`), KEY `plr_skills` (`plr_bot`,`plr_kills`,`plr_frags`,`plr_deaths`), KEY `plr_sdeaths` (`plr_bot`,`plr_deaths`,`plr_frags`), KEY `plr_ssuicides` (`plr_bot`,`plr_suicides`,`plr_frags`,`plr_deaths`), KEY `plr_seff` (`plr_bot`,`plr_eff`,`plr_kills`,`plr_frags`,`plr_deaths`), KEY `plr_sfph` (`plr_bot`,`plr_fph`,`plr_kills`,`plr_frags`,`plr_deaths`), KEY `plr_ssph` (`plr_bot`,`plr_sph`,`plr_kills`,`plr_frags`,`plr_deaths`), KEY `plr_smatches` (`plr_bot`,`plr_matches`,`plr_kills`,`plr_frags`,`plr_deaths`), KEY `plr_stime` (`plr_bot`,`plr_time`,`plr_kills`,`plr_frags`,`plr_deaths`), KEY `plr_sfrags` (`plr_bot`,`plr_frags`,`plr_deaths`), KEY `plr_swins` (`plr_bot`,`plr_wins`,`plr_teamwins`,`plr_matches`,`plr_kills`,`plr_frags`,`plr_deaths`) ) ENGINE=MyISAM AUTO_INCREMENT=2095 DEFAULT CHARSET=latin1
[14 Jan 2008 18:32]
FnG Lambik
Hello, addition to previous post : I noticed the 'USE plr_sscore' part, so you might want to know the index too ? fiels in index : plr_bot, plr_frags, plr_deaths, index type : unique My appologies for reporting the INNODB part, I am not much of a database person. Lambik
[1 Feb 2008 10:15]
Valeriy Kravchuk
Please, try to repeat with a newer version, 5.0.51a, and inform about the results.
[2 Mar 2008 0: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".
[6 Mar 2008 11:08]
Nick Nott
I'm also experiencing this problem even on 5.0.51a: 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=0x455fcfe0, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) Stack trace seems successful - bottom reached 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 0x2918ba0 = SELECT t.topic_id FROM phpbb_topics t WHERE t.topic_last_post_time > 1204640724 AND t.topic_moved_id = 0 AND t.topic_approved = 1 AND t.forum_id NOT IN (78, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 92, 93, 94, 95, 98, 99, 100, 101, 119) ORDER BY t.topic_last_post_time DESC LIMIT 1001 thd->thread_id=4724 Explain seems to be working: mysql> explain SELECT t.topic_id FROM phpbb_topics t WHERE t.topic_last_post_time > 1204640724 AND t.topic_moved_id = 0 AND t.topic_approved = 1 AND t.forum_id NOT IN (78, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 92, 93, 94, 95, 98, 99, 100, 101, 119) ORDER BY t.topic_last_post_time DESC LIMIT 1001; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 782 Current database: masterDB +----+-------------+-------+-------+-------------------------------------------------------------------------------------+---------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+-------------------------------------------------------------------------------------+---------+---------+------+------+-------------+ | 1 | SIMPLE | t | range | forum_id,forum_id_type,last_post_time,topic_approved,forum_appr_last,fid_time_moved | PRIMARY | 0 | NULL | 178 | Using where | +----+-------------+-------+-------+-------------------------------------------------------------------------------------+---------+---------+------+------+-------------+ 1 row in set (0.00 sec) mysql>
[17 Mar 2008 10:19]
Susanne Ebrecht
set to open again because last feedback was given.
[17 Mar 2008 10:39]
Bogdan Kecman
Cannot duplicate behavior. tested with phpBB3 using MySQL 5.0.45 and 5.0.51 - phpBB works fine, mysql works fine. tested queries directly on MySQL using phpBB tables - works fine
[17 Mar 2008 11:05]
Nick Nott
Were you using 64 bit ? I've installed MySQL 32 bit and since then everything seems to be working OK, but the problem exists(ed) in 64 bit.
[19 Mar 2008 17:55]
Bogdan Kecman
I have tested both 32 and 64 bit version of MySQL (5.0.45 32 bit running on 32 bit OS and 5.0.51 64 bit running on 64bit OS) - both phpBB systems were previously running phpBB2 upgraded to phpBB3 (rc5) then upgraded to phpBB3 (3.0.0)
[2 Apr 2008 9:01]
FnG Lambik
Well I did AGAIN install the requested 5.0.51a version of mysql, and no supprise that it didn't work either. Unless you MySQL support ppl can come up with a serious solution, then I don't want to be part of the bug reporting thing. I don't mind if there isn't enough resources to investigate the problem, and so even resources to fix it, but I do mind the fact that after every minor release you guys ask to install that version. When there is something fixed in that minor version which remotely can be related to this bug, then I understand, but that has not been the case. I have now installed the 32-bit verion of 5.0.51a and that seems to be stable now. thank you for your support (somehow :?), thanks Georgi Kolev for mentioning your 32-bit version was stable :D that did the trick for me. Lambik
[16 Jun 2008 11:19]
Georgi Kolev
Hello again. Today I decided to update my distro with the newest packets with yast online_update. After that i uninstalled all 32bit Mysql-related packets and installed the last version of Mysql x86_64 5.0.51a-0 (but not from suse repository, I downloaded the suse rpms from mysql.com - http://dev.mysql.com/downloads/mysql/5.0.html#linux-sles10-x86-64bit-rpms ). And all works fine now! :)
[19 Aug 2008 15:41]
Thomas buck
I am also experiencing this bug on opensuse 10.3, 64-bit editions of both MySQL and SuSE. I believe that something's up with some random library on opensuse that is causing the 64-bit edition of MySQL to crash, whilst leaving the 32-bit version. If anyone else is experiencing this issue, please add a comment and let's get our voices heard!
[20 Aug 2008 12:17]
Thomas buck
Hrm, just managed to fix this for myself. Just now, I ran Online Update, updated everything (including scary glibc update!), which went smoothly. I restarted MySQL... and now the bug's gone. Would love to have the time to install each update one-by-one to find out where the bug lies, but this has fixed it for me, hopefully it'll fix it for you.
[8 Mar 2009 16:03]
Eric Gurevitz
I ran into this bug on Open SUSE 10.3. I upgraded to the latest version of mysql at www.mysql.com and the queries that use 'Order By DESC' are now working. We did not have this problem on Suse Enterprise Server. Thanks for everyone who wrote. Eric
