MySQL Bugs: #62740: Crashes during startup in crash recovery InnoDB

Bug #62740	Crashes during startup in crash recovery InnoDB
Submitted:	14 Oct 2011 15:34	Modified:	13 Jun 2013 12:20
Reporter:	Jan Bromberger	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	5.5.15	OS:	MacOS (10.6.8)
Assigned to:		CPU Architecture:	Any
Tags:	crash recovery, innodb

Description:
After a power failure during an import script. Now every time I start mysqld_safe, it instantly crashes.

I'm using "mysqld  Ver 5.5.15 for osx10.6 on i386 (Source distribution)" installed via homebrew.

111014 17:27:22 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
111014 17:27:22 InnoDB: The InnoDB memory heap is disabled
111014 17:27:22 InnoDB: Mutexes and rw_locks use GCC atomic builtins
111014 17:27:22 InnoDB: Compressed tables use zlib 1.2.3
111014 17:27:22 InnoDB: Initializing buffer pool, size = 128.0M
111014 17:27:22 InnoDB: Completed initialization of buffer pool
111014 17:27:22 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 37985448571
111014 17:27:22  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...
InnoDB: Doing recovery: scanned up to log sequence number 37985453683
111014 17:27:22  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 111014 17:27:22 - 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=33554432
read_buffer_size=131072
max_used_connections=0
max_threads=30
thread_count=0
connection_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 98387 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 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 = 0x0 thread_stack 0x40000
0   mysqld                              0x000000010030e689 my_print_stacktrace + 57
1   mysqld                              0x0000000100121f82 handle_segfault + 834
2   libSystem.B.dylib                   0x00007fff873051ba _sigtramp + 26
3   ???                                 0x0000000000000000 0x0 + 0
4   mysqld                              0x00000001003b17cd rec_get_n_owned_new + 13
5   mysqld                              0x00000001003934a2 page_rec_find_owner_rec + 98
6   mysqld                              0x000000010038e200 page_cur_insert_rec_low + 368
7   mysqld                              0x000000010038f704 page_cur_parse_insert_rec + 772
8   mysqld                              0x00000001003807bd recv_parse_or_apply_log_rec_body + 2125
9   mysqld                              0x0000000100381200 recv_recover_page_func + 752
10  mysqld                              0x000000010033b630 buf_page_io_complete + 1136
11  mysqld                              0x000000010035a4a8 fil_aio_wait + 488
12  mysqld                              0x00000001003d49d8 io_handler_thread + 88
13  libSystem.B.dylib                   0x00007fff872ddfd6 _pthread_start + 331
14  libSystem.B.dylib                   0x00007fff872dde89 thread_start + 13
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.

How to repeat:
Happens on every start with my assumable corrupted files.

Please, send the entire error log (compressed) and my.cnf file content. 

How large is the entire (probably corrupted) content of your datadir and can you share it?

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".

Verified as described on OSX Mountain Lion using 5.6.11:

2013-06-13 09:40:46 1316 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 08:40:46 UTC - 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=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68210 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 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 = 0 thread_stack 0x40000
0   mysqld                              0x00000001068f5092 my_print_stacktrace + 44
1   mysqld                              0x0000000106750a30 handle_fatal_signal + 705
2   libsystem_c.dylib                   0x00007fff99a0194a _sigtramp + 26
3   ???                                 0x00007facfb40f2b8 0x0 + 140380926440120
4   mysqld                              0x00000001069de88c _Z25page_cur_parse_insert_recmPhS_P11buf_block_tP12dict_index_tP5mtr_t + 1385
5   mysqld                              0x00000001069d16e6 _ZL32recv_parse_or_apply_log_rec_bodyhPhS_P11buf_block_tP5mtr_tm + 246
6   mysqld                              0x00000001069d10ef _Z22recv_recover_page_funcmP11buf_block_t + 1693
7   mysqld                              0x00000001069392fb _Z20buf_page_io_completeP10buf_page_t + 1686
8   mysqld                              0x00000001069719f2 _Z12fil_aio_waitm + 355
9   mysqld                              0x0000000106a36078 io_handler_thread + 58
10  libsystem_c.dylib                   0x00007fff99a137a2 _pthread_start + 327
11  libsystem_c.dylib                   0x00007fff99a001e1 thread_start + 13
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.
130613 09:40:46 mysqld_safe mysqld from pid file /usr/local/mysql/data/Cerberus.local.pid ended

Will this bug be fixed ?

will you fix this bugs?
I have meet the same problem in MySQL8.0 recently

I just came across this bug, while searching for bugs online and am curious to know what was the setting for innodb_flush_log_at_trx_commit, when you encountered this bug?

Any progress about this bug?

I just came across the same bug in the lastest MySQL 5.7 version.

This bug is the original bug for the following bug:

https://bugs.mysql.com/bug.php?id=108156

Hi chen zongzhi,
"I have meet the same problem in MySQL8.0 recently"

- Could you please let us know which version of 8.0 this issue is seen?
- Is it reproducible? if yes, could you please share the steps to reproduce it.