| Bug #30493 | MySQL 6 Falcon Critical crash when doing any query after some long time of using | ||
|---|---|---|---|
| Submitted: | 18 Aug 2007 23:59 | Modified: | 18 Nov 2007 22:47 |
| Reporter: | Piotr Klimczak | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: Falcon storage engine | Severity: | S1 (Critical) |
| Version: | 6.0.3 Alpha | OS: | Linux (SuSE 10.3 GM) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | Crash Falcon | ||
[19 Aug 2007 0:10]
Piotr Klimczak
Using mysql database still works...
[6 Sep 2007 6:54]
Valeriy Kravchuk
Thank you for a detailed problem report. Can you identify and send queries that lead to these crashes?
[6 Sep 2007 9:17]
Piotr Klimczak
Sorry (my bad), i forgotten to mention that it happens just after the shutdown and startup again the MySQL... So it's crushed right after the start up probably w/o performing any query... (failure occur when performing basic queries like select except "use". Mysql shutdown it self and generate described bug reports). The problem is probably associated mainly with falcon storge engine as when it happens then all databases which have at least one falcon table are corrupted. Other works unless performing query to falcon table. I will try to generate this problem on kind of test database and then send you corrupted database files. But this could take me some longer time...
[6 Sep 2007 10:16]
Kevin Lewis
Piotr, I would recommend trying the 6.0.2-alpha release to see if the problem still exists.
[19 Sep 2007 14:35]
Hakan Küçükyılmaz
Can you still reproduce the problem?
[19 Sep 2007 16:22]
Piotr Klimczak
Well, the most updated version seems to be very stable, and no errors arise in {HOST}.err log file... I think we can close this bug and if it happend again i will come back to this report... but i doubt...
Thank you for your time
Best regards
Piotr Klimczak
[1 Oct 2007 21:17]
Piotr Klimczak
Unfortunately it happend again after longer time.... looks exactly the same... Nothing defferent was done.... I know that this description is a kind of useless as there is no how to reapeat info, but i have no idea how to repeat it. It just happens after about month without performing any extraordinary queries... just simple queries on falcon tables, using up to 3 tables in one query, transactions and other simple things... Hardware failure is rather not possible as all the time all other things works fine... Hope you will find thins difficult bug....
[16 Oct 2007 11:36]
Hakan Küçükyılmaz
Piotr, thanks for testing Falcon. Can you try to reproduce the crash? Best regards, Hakan
[16 Oct 2007 12:30]
Piotr Klimczak
Few days ago i have downloaded (using BK) the newest version (about 12th X 2007). Problem occurs always about 1 month of after installation w/o doing anything different than just daily things. So as i guess i have to wait to see if it happened again. One question: i have stored all crushed databases, so would it be helpful if i upload it to you? As i guess if you find a crushed place in DB files, then it would be easier to find the code which case the crush. (i guess something is wrong with starting or stopping the DB as it always happens just after DB start) So? Do you want me to upload it?
[18 Oct 2007 22:47]
Kevin Lewis
Piotr, If you suspect that the engine might crash on restart, please copy off the all the falcon files including the log files before the restart. Then if it fails, send them to us. The log files will be critical in figuring out what is wrong. Even if it is just after the crash, please send the log files too.
[19 Nov 2007 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".
[31 Jan 2008 4:59]
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/41473
[31 Jan 2008 5:10]
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/41474
Description: MySQL crashes every time just after doing any query when using innoDB and Falcon based databases. But still may use test database, and do queries and even create tables unless create falcon table. after that using test database also started to case crashes... can`t create any new database. How to repeat: not sure how to generate this bug... It have happend after quite long time (3 weeks) of using the falcon engine as starge engine for own CMS... Was working all the time w/o problems. Nothing different was done before first crush than daily things except one thing- data was dumped to file and then from file to mysql. but it was still working for 1 day. After that i have deleted databases directory and created it from very beginning by mysql_install_db. Then have created databases and loaded data from dumped file. Since that moment it was working again for 1 day and started to crash form the very beginning. I'll try to do some things again and then will let you know if get more informations The {HOST}.err file contains Number of processes running now: 0 070819 01:42:15 mysqld restarted 070819 1:42:16 InnoDB: Started; log sequence number 0 3030624 070819 1:42:16 [Note] Event Scheduler: Loaded 0 events 070819 1:42:16 [Note] /local/Main/Builded/mysql6/libexec/mysqld: ready for connections. Version: '6.0.2-alpha' socket: '/tmp/mysql.sock' port: 3306 Source distribution 070819 1:42:23 - mysqld got signal 4; 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_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 = 337593 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x8b8cb38 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=0xb4b85bf8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81f65ff 0xffffe410 0x83a0086 0x83a0100 0x84219e4 0x8422c16 0x83d9a04 0x8396b05 0x83fdb32 0x83e3d3e 0x8391614 0x8386e54 0x8389179 0x835cccf 0x835f467 0x835fc53 0x83583c1 0x82d08a5 0x8246cc9 0x823d43f 0x82439c3 0x82440ba 0x82442b7 0x82ecba3 0x820e849 0x820f637 0x81ff1de 0xb7e23192 0xb7d2ad2e New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.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 0x8bb7c10 = 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. The resolve stack dump have returned the following text: 0x81f65ff handle_segfault + 767 0xffffe410 _end + -141360524 0x83a0086 _ZN5Error5errorEPKcz + 86 0x83a0100 _ZN5Error15assertionFailedEPKci + 32 0x84219e4 _ZN17RecordLocatorPage12setIndexSlotEiiii + 276 0x8422c16 _ZN17RecordLocatorPage10deleteLineEii + 54 0x83d9a04 _ZN7Section12updateRecordEiP6Streamjb + 1028 0x8396b05 _ZN3Dbb12updateRecordEiiP6Streamjb + 85 0x83fdb32 _ZN16SRLUpdateRecords4redoEv + 530 0x83e3d3e _ZN9SerialLog7recoverEv + 1438 0x8391614 _ZN8Database12openDatabaseEPKc + 260 0x8386e54 _ZN10Connection11getDatabaseEPKcS1_P7Threads + 228 0x8389179 _ZN10Connection12openDatabaseEPKcS1_S1_S1_S1_P7Threads + 153 0x835cccf _ZN15StorageDatabase17getOpenConnectionEv + 111 0x835f467 _ZN14StorageHandler10initializeEv + 151 0x835fc53 _ZN14StorageHandler20getStorageConnectionEP17StorageTableShareP3THDi10OpenOptioni + 611 0x83583c1 _ZN16StorageInterface4openEPKcij + 129 0x82d08a5 _ZN7handler7ha_openEP8st_tablePKcii + 53 0x8246cc9 _Z21open_table_from_shareP3THDP14st_table_sharePKcjjjP8st_tableb + 1337 0x823d43f _Z17open_unireg_entryP3THDP8st_tableP13st_table_listPKcPcjP11st_mem_rootj + 159 0x82439c3 _Z10open_tableP3THDP13st_table_listP11st_mem_rootPbj + 2499 0x82440ba _Z11open_tablesP3THDPP13st_table_listPjj + 714 0x82442b7 _Z30open_normal_and_derived_tablesP3THDP13st_table_listj + 39 0x82ecba3 _Z18mysqld_list_fieldsP3THDP13st_table_listPKc + 35 0x820e849 _Z16dispatch_command19enum_server_commandP3THDPcj + 2585 0x820f637 _Z10do_commandP3THD + 167 0x81ff1de handle_one_connection + 222 0xb7dee192 _end + -1351483402 0xb7cf5d2e _end + -1352500334 then another in {HOST}.err when trying to do queries on test databases: Number of processes running ence number 0 3030624 070819 1:43:44 [Note] Event Scheduler: Loaded 0 events 070819 1:43:44 [Note] /local/Main/Builded/mysql6/libexec/mysqld: ready for connections. Version: '6.0.2-alpha' socket: '/tmp/mysql.sock' port: 3306 Source distribution 070819 1:44:00 - mysqld got signal 4; 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_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 = 337593 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x8b8cb38 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=0xb4bedbf8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81f65ff 0xffffe410 0x83a0086 0x83a0100 0x84219e4 0x8422c16 0x83d9a04 0x8396b05 0x83fdb32 0x83e3d3e 0x8391614 0x8386e54 0x8389179 0x835cccf 0x835f467 0x835fc53 0x83583c1 0x82d08a5 0x8246cc9 0x823d43f Stack trace seems successful - bottom reached Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.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 0x8bb7aa8 = 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. where the resolve stack dum generates: 0x81f65ff handle_segfault + 767 0xffffe410 _end + -141360524 0x83a0086 _ZN5Error5errorEPKcz + 86 0x83a0100 _ZN5Error15assertionFailedEPKci + 32 0x84219e4 _ZN17RecordLocatorPage12setIndexSlotEiiii + 276 0x8422c16 _ZN17RecordLocatorPage10deleteLineEii + 54 0x83d9a04 _ZN7Section12updateRecordEiP6Streamjb + 1028 0x8396b05 _ZN3Dbb12updateRecordEiiP6Streamjb + 85 0x83fdb32 _ZN16SRLUpdateRecords4redoEv + 530 0x83e3d3e _ZN9SerialLog7recoverEv + 1438 0x8391614 _ZN8Database12openDatabaseEPKc + 260 0x8386e54 _ZN10Connection11getDatabaseEPKcS1_P7Threads + 228 0x8389179 _ZN10Connection12openDatabaseEPKcS1_S1_S1_S1_P7Threads + 153 0x835cccf _ZN15StorageDatabase17getOpenConnectionEv + 111 0x835f467 _ZN14StorageHandler10initializeEv + 151 0x835fc53 _ZN14StorageHandler20getStorageConnectionEP17StorageTableShareP3THDi10OpenOptioni + 611 0x83583c1 _ZN16StorageInterface4openEPKcij + 129 0x82d08a5 _ZN7handler7ha_openEP8st_tablePKcii + 53 0x8246cc9 _Z21open_table_from_shareP3THDP14st_table_sharePKcjjjP8st_tableb + 1337 0x823d43f _Z17open_unireg_entryP3THDP8st_tableP13st_table_listPKcPcjP11st_mem_rootj + 159 I hope it will help... if need more info then give me a sign...