Bug #47931 | assert upon startup : "frag_n_used > 0" | ||
---|---|---|---|
Submitted: | 9 Oct 2009 8:26 | Modified: | 11 Oct 2009 5:35 |
Reporter: | Richlv - | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server | Severity: | S2 (Serious) |
Version: | 5.1.39 | OS: | Linux (slackware 13.0) |
Assigned to: | CPU Architecture: | Any | |
Tags: | assert, frag_n_used |
[9 Oct 2009 8:26]
Richlv -
[9 Oct 2009 9:16]
Valeriy Kravchuk
Thank you for the problem report. Please, upload your entire error log. I had never seen this assertion (it is in fsp_free_page() function that is used to free single page of space)...
[9 Oct 2009 9:26]
Richlv -
that is the whole error log, there is nothing more logged.
[9 Oct 2009 9:48]
Valeriy Kravchuk
Sorry, I don't believe you. Normal log can NOT start with: 091009 11:20:14 mysqld_safe Starting mysqld daemon with databases from /usr/local/var InnoDB: Log scan progressed past the checkpoint lsn 5 4179754997 091009 11:20:19 InnoDB: Database was not shut down normally! There should be infromation about previous startup, for example. So, you either cleared the log somehow before this startup, or do not send it entirely. We need to know what happend before this startup attempt. Check also your OS logs (/var/log/messages etc) for possible hardware failure messages.
[9 Oct 2009 9:51]
Richlv -
true, previous logfile entries were cleared. there are no hardware failures logged anywhere. actually, turns out i had grabbed logfile before it was fully printed... a moment later backtrace was printed, which might be useful ;) thd: 0x0 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 = (nil) thread_stack 0x30000 /usr/local/libexec/mysqld(my_print_stacktrace+0x1d) [0x847f35d] /usr/local/libexec/mysqld(handle_segfault+0x2fa) [0x81cbb9a] [0xffffe400] /lib/libc.so.6(abort+0x188) [0xb7d3ee08] /usr/local/libexec/mysqld [0x838591b] /usr/local/libexec/mysqld [0x83f9f9e] /usr/local/libexec/mysqld(trx_undo_truncate_end+0x548) [0x83fc218] /usr/local/libexec/mysqld(trx_roll_pop_top_rec_of_trx+0x97a) [0x83f329a] /usr/local/libexec/mysqld(row_undo_step+0x282) [0x83d7f42] /usr/local/libexec/mysqld(que_run_threads+0x554) [0x83bd484] /usr/local/libexec/mysqld(trx_rollback_or_clean_all_without_sess+0x357) [0x83f1db7] /lib/libpthread.so.0 [0xb7ff7310] /lib/libc.so.6(clone+0x5e) [0xb7df4bee] 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. 091009 12:48:40 mysqld_safe mysqld from pid file /usr/local/var/rich.pid ended
[9 Oct 2009 10:01]
Valeriy Kravchuk
The only bug with a similar stack trace (although other assertion failed) is http://bugs.mysql.com/bug.php?id=15717. Still, OS/hardware failure is the most probable reason, according to Heikki. Please, double check.
[9 Oct 2009 10:30]
Richlv -
well, i just thought that asserting is bad in any case (and i haven't found any hardware issues). as i did not have any critical databases there and the ones i was interested in could be dumped with innodb_force_recovery = 3, i just nuked the old data, which made mysql happy. feel free to close this report.
[11 Oct 2009 5:35]
Sveta Smirnova
Thank you for the feedback. Closing as "Can't repeat" for now. If you meet this again don't clean up error log file, check your disk and RAM (memtest is good for RAM checking) and reopen the report in case if problem not in hardware.