Comment 8 for bug 1155475

Revision history for this message
Sergei Glushchenko (sergei.glushchenko) wrote :

To reproduce

1. Start server with archiving turned on
2. Load some data into tables for archived log file to be created
3. Restart server
4. Execute 'PURGE ARCHIVES LOGS BEFORE NOW()'
5. Shutdown server

Instead of normal shutdown following will be printed:
130316 18:06:57 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
130316 18:06:57 InnoDB: File name /Users/sergei/percona/repo/log-arch/usr/local/mysql/data/ib_log_archive_0000000175350784
130316 18:06:57 InnoDB: File operation call: 'open' returned OS error 71.
130316 18:06:57 InnoDB: Cannot continue operation.
130316 18:06:57 InnoDB: Assertion failure in thread 4450070528 in file os0file.cc line 662
InnoDB: Failing assertion: 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:06:57 UTC - 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=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 = 68253 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 0x0000000101d01be7 my_print_stacktrace + 55
1 mysqld 0x000000010199484e handle_fatal_signal + 1070
2 libsystem_c.dylib 0x00007fff8aa28cfa _sigtramp + 26
3 ??? 0x00000001093ea048 0x0 + 4450066504
4 libsystem_c.dylib 0x00007fff8a9c7a7a abort + 143
5 mysqld 0x0000000101efd239 _ZL30os_file_handle_error_cond_exitPKcS0_mm + 585
6 mysqld 0x0000000101ef6b11 _ZL20os_file_handle_errorPKcS0_ + 49
7 mysqld 0x0000000101ef7b25 _Z19os_file_create_funcPKcmmmPm + 869
8 mysqld 0x0000000101ede2cf _ZL23pfs_os_file_create_funcjPKcmmmPmS0_m + 239
9 mysqld 0x0000000101eddbe2 _ZL17log_group_archiveP11log_group_t + 690
10 mysqld 0x0000000101edd448 _ZL18log_archive_groupsv + 120
11 mysqld 0x0000000101edd34b _ZL32log_archive_check_completion_lowv + 251
12 mysqld 0x0000000101ed7f55 _ZL23log_io_complete_archivev + 245
13 mysqld 0x0000000101ed7d95 _Z15log_io_completeP11log_group_t + 37
14 mysqld 0x0000000101e1a711 _Z12fil_aio_waitm + 577
15 mysqld 0x00000001020003fd io_handler_thread + 125
16 libsystem_c.dylib 0x00007fff8a9d48bf _pthread_start + 335
17 libsystem_c.dylib 0x00007fff8a9d7b75 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.