XAMPP MySQL starts then stops - mysql

So I've tried a lot of things and can't get my SQL to work (Apache is working)
Here is the error log. All it does is show green in the control panel then just stops.
2018-04-14 14:42:34 37c InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2018-04-14 14:42:34 892 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
2018-04-14 14:42:34 892 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2018-04-14 14:42:34 892 [Note] InnoDB: The InnoDB memory heap is disabled
2018-04-14 14:42:34 892 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2018-04-14 14:42:34 892 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier
2018-04-14 14:42:34 892 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-04-14 14:42:34 892 [Note] InnoDB: Using generic crc32 instructions
2018-04-14 14:42:34 892 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2018-04-14 14:42:34 892 [Note] InnoDB: Completed initialization of buffer pool
2018-04-14 14:42:34 892 [Note] InnoDB: Highest supported file format is Barracuda.
2018-04-14 14:42:34 892 [Note] InnoDB: The log sequence number 0 in ibdata file do not match the log sequence number 1835107 in the ib_logfiles!
2018-04-14 14:42:34 37c InnoDB: Assertion failure in thread 892 in file fsp0fsp.cc line 1880
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
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.
180414 14:42:34 [ERROR] mysqld got exception 0x80000003 ;
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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
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.
Server version: 10.1.31-MariaDB
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=0
max_threads=1001
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787129 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...
mysqld.exe!my_parameter_handler()
mysqld.exe!strxnmov()
mysqld.exe!?propagate_equal_fields#Item##UAEPAV1#PAVTHD##ABVContext#Value_source##PAVCOND_EQUAL###Z()
mysqld.exe!?propagate_equal_fields#Item##UAEPAV1#PAVTHD##ABVContext#Value_source##PAVCOND_EQUAL###Z()
mysqld.exe!?get_key#MDL_ticket##QBEPAVMDL_key##XZ()
mysqld.exe!?propagate_equal_fields#Item##UAEPAV1#PAVTHD##ABVContext#Value_source##PAVCOND_EQUAL###Z()
mysqld.exe!?get_select_id#Explain_basic_join##UAEHXZ()
mysqld.exe!?ha_initialize_handlerton##YAHPAUst_plugin_int###Z()
mysqld.exe!?plugin_init##YAHPAHPAPADH#Z()
mysqld.exe!?plugin_init##YAHPAHPAPADH#Z()
mysqld.exe!?init_net_server_extension##YAXPAVTHD###Z()
mysqld.exe!?win_main##YAHHPAPAD#Z()
mysqld.exe!?mysql_service##YAHPAX#Z()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlGetAppContainerNamedObjectPath()
ntdll.dll!RtlGetAppContainerNamedObjectPath()
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.
Here is the other code
2:42:33 PM [mysql] Attempting to start MySQL service...
2:42:34 PM [mysql] Status change detected: running
2:42:36 PM [mysql] Status change detected: stopped
2:42:36 PM [mysql] Error: MySQL shutdown unexpectedly.
2:42:36 PM [mysql] This may be due to a blocked port, missing dependencies,
2:42:36 PM [mysql] improper privileges, a crash, or a shutdown by another method.
2:42:36 PM [mysql] Press the Logs button to view error logs and check
2:42:36 PM [mysql] the Windows Event Viewer for more clues
2:42:36 PM [mysql] If you need more help, copy and post this
2:42:36 PM [mysql] entire log window on the forums
I am running Windows 10.

For the record. I'm getting this exact same error on several different machines. All seem to be virus free. I would say a serious bug has escaped debugging and development. It may require an earlier install of Xampp or checking the MD5 to make sue there isn't a compromise of the distribution

Related

Mysql service would not restart anymore

My mysql server couldn' t not restart anymore
i was doing the installation of a wordpress plugin, it crashed, then i tried to relaunch the service, I have the error:
root#ns3371000:~# /etc/init.d/mysql start
[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
This is the log when i launch it in safe mode:
mysqld_safe Logging to '/var/log/mysql.err'.
180822 16:33:07 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180822 16:33:07 [Note] Plugin 'FEDERATED' is disabled.
180822 16:33:07 InnoDB: The InnoDB memory heap is disabled
180822 16:33:07 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180822 16:33:07 InnoDB: Compressed tables use zlib 1.2.7
180822 16:33:07 InnoDB: Using Linux native AIO
180822 16:33:07 InnoDB: Initializing buffer pool, size = 128.0M
180822 16:33:07 InnoDB: Completed initialization of buffer pool
180822 16:33:07 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 12059835
180822 16:33:07 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: Error: tried to read 65536 bytes at offset 0 2358272.
InnoDB: Was only able to read 1024.
InnoDB: Fatal error: cannot read from file. OS error number 17.
180822 16:33:10 InnoDB: Assertion failure in thread 140608317830944 in file os0file.c line 2549
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:33:10 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=16777216
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 = 346701 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x56449ac71dc9]
/usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x56449ab57dc8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x7fe1ec9460a0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fe1eb1d6125]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x180)[0x7fe1eb1d93a0]
/usr/sbin/mysqld(+0x67926b)[0x56449ada926b]
/usr/sbin/mysqld(+0x63eca0)[0x56449ad6eca0]
/usr/sbin/mysqld(+0x66b906)[0x56449ad9b906]
/usr/sbin/mysqld(+0x670eb7)[0x56449ada0eb7]
/usr/sbin/mysqld(+0x5ce70f)[0x56449acfe70f]
/usr/sbin/mysqld(+0x59aa2f)[0x56449accaa2f]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x56449ab5a151]
/usr/sbin/mysqld(+0x336507)[0x56449aa66507]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa73)[0x56449aa69553]
/usr/sbin/mysqld(+0x2bb695)[0x56449a9eb695]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x45b)[0x56449a9ec30b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7fe1eb1c2ead]
/usr/sbin/mysqld(+0x2b2c89)[0x56449a9e2c89]
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.
I don' t want to loose all my current databases, anything pointing me to sort out the issues would be greatful
Thanks
If the database is broken you can try to access it in a recovery mode.
In your configuration file (my.ini) try to add:
[mysqld]
innodb_force_recovery = N
where N is from 1 to 6. Then, restart the server.
More information here: https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
At least, you should be able to access the database in read-only mode to do the dump.

mysqld.exe has stopped working. Trying to start mysql in XAMPP

Right now I am learning how to code HTML and PHP and use SQL. I am using XAMPP for mysql. Whenever I try to start mysql I always get an error. This is the error log.
2018-02-24 17:22:30 f04 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2018-02-24 17:22:30 3844 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
2018-02-24 17:22:31 3844 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2018-02-24 17:22:31 3844 [Note] InnoDB: The InnoDB memory heap is disabled
2018-02-24 17:22:31 3844 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2018-02-24 17:22:31 3844 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier
2018-02-24 17:22:31 3844 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-02-24 17:22:31 3844 [Note] InnoDB: Using generic crc32 instructions
2018-02-24 17:22:31 3844 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2018-02-24 17:22:31 3844 [Note] InnoDB: Completed initialization of buffer pool
2018-02-24 17:22:31 3844 [Note] InnoDB: The first specified data file C:\xampp\mysql\data\ibdata1 did not exist: a new database to be created!
2018-02-24 17:22:31 3844 [Note] InnoDB: Setting file C:\xampp\mysql\data\ibdata1 size to 10 MB
2018-02-24 17:22:31 3844 [Note] InnoDB: Setting log file C:\xampp\mysql\data\ib_logfile101 size to 5 MB
2018-02-24 17:22:31 3844 [Note] InnoDB: Setting log file C:\xampp\mysql\data\ib_logfile1 size to 5 MB
2018-02-24 17:22:31 f04 InnoDB: Error: Write to file C:\xampp\mysql\data\ib_logfile101 failed at offset 0.
InnoDB: 512 bytes should have been written, only 0 were written.
InnoDB: Operating system error number 87.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: FormatMessage: Error number 87 means 'The parameter is incorrect.
'.
InnoDB: Error number 87 means 'Unknown error'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
2018-02-24 17:22:31 f04 InnoDB: Operating system error number 87 in a file operation.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
InnoDB: Operation os_file_write_func to file D:\win32-packages\build\src\storage\xtradb\os\os0file.cc and at line 5097
2018-02-24 17:22:31 3844 [ERROR] InnoDB: File C:\xampp\mysql\data\ib_logfile101: 'os_file_write_func' returned OS error 287. Cannot continue operation
180224 17:22:31 [ERROR] mysqld got exception 0x80000003 ;
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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
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.
Server version: 10.1.30-MariaDB
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=0
max_threads=1001
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787129 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...
mysqld.exe!my_parameter_handler()
mysqld.exe!strxnmov()
mysqld.exe!?compare_ulonglong##YAHPB_K0#Z()
mysqld.exe!no_key()
mysqld.exe!no_key()
mysqld.exe!no_key()
mysqld.exe!no_key()
mysqld.exe!no_key()
mysqld.exe!no_key()
mysqld.exe!no_key()
mysqld.exe!?compare_ulonglong##YAHPB_K0#Z()
mysqld.exe!?compare_ulonglong##YAHPB_K0#Z()
mysqld.exe!?str_result#Item##UAEPAVString##PAV2##Z()
mysqld.exe!?ha_initialize_handlerton##YAHPAUst_plugin_int###Z()
mysqld.exe!?plugin_init##YAHPAHPAPADH#Z()
mysqld.exe!?plugin_init##YAHPAHPAPADH#Z()
mysqld.exe!?init_net_server_extension##YAXPAVTHD###Z()
mysqld.exe!?win_main##YAHHPAPAD#Z()
mysqld.exe!?mysql_service##YAHPAX#Z()
mysqld.exe!strxnmov()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlGetAppContainerNamedObjectPath()
ntdll.dll!RtlGetAppContainerNamedObjectPath()
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.
I have tried deleting the ibdata1, ib_logfile1 and ib_logfile0 and the mysql_error in the C:\xampp\mysql\data folder but it hasn't helped. I dont know what to do and how to fix it. I have read other questions on this website and topic but none of the solutions given help me. Please help!

mysqld.exe has stopped working in xampp windows?

Mysqld.exe has stopped working in xampp windows.
I started my computer while the XAMPP software was running in the background, MySQL will not start!
2017-11-20 11:05:36 14f4 InnoDB: Warning: Using
innodb_additional_mem_pool_size is DEPRECATED. This option may be
removed in future releases, together with the option
innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2017-11-20 11:05:36 5364 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of
small buffer pool size. In order to use backoff, increase buffer pool
at least up to 20MB.
2017-11-20 11:05:36 5364 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2017-11-20 11:05:36 5364 [Note] InnoDB: The InnoDB memory heap is disabled
2017-11-20 11:05:36 5364 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2017-11-20 11:05:36 5364 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier
2017-11-20 11:05:36 5364 [Note] InnoDB: Compressed tables use zlib 1.2.3
2017-11-20 11:05:36 5364 [Note] InnoDB: Using generic crc32 instructions
2017-11-20 11:05:36 5364 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2017-11-20 11:05:36 5364 [Note] InnoDB: Completed initialization of buffer pool
2017-11-20 11:05:37 5364 [Note] InnoDB: Highest supported file format is Barracuda.
2017-11-20 11:05:37 5364 [Note] InnoDB: The log sequence number 1835037 in ibdata file do not match the log sequence number
11035100176 in the ib_logfiles!
2017-11-20 11:05:37 14f4 InnoDB: Operating system error number 38 in a file operation.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
InnoDB: Operation read to file D:\win32-packages\build\src\storage\xtradb\os\os0file.cc and at line
3174
2017-11-20 11:05:37 5364 [ERROR] InnoDB: File (unknown): 'read' returned OS error 238. Cannot continue operation
171120 11:05:37 [ERROR] mysqld got exception 0x80000003 ;
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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
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.
Server version: 10.1.25-MariaDB
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=0
max_threads=1001
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787107 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...
mysqld.exe!my_parameter_handler()
mysqld.exe!strxnmov()
mysqld.exe!?element_index#Item##UAEPAV1#I#Z()
mysqld.exe!?element_index#Item##UAEPAV1#I#Z()
mysqld.exe!?element_index#Item##UAEPAV1#I#Z()
mysqld.exe!?element_index#Item##UAEPAV1#I#Z()
mysqld.exe!?element_index#Item##UAEPAV1#I#Z()
mysqld.exe!?element_index#Item##UAEPAV1#I#Z()
mysqld.exe!?element_index#Item##UAEPAV1#I#Z()
mysqld.exe!?element_index#Item##UAEPAV1#I#Z()
mysqld.exe!?element_index#Item##UAEPAV1#I#Z()
mysqld.exe!?fix_length_and_dec#subselect_partial_match_engine##UAEXPAPAVItem_cache###Z()
mysqld.exe!?ha_initialize_handlerton##YAHPAUst_plugin_int###Z()
mysqld.exe!?plugin_init##YAHPAHPAPADH#Z()
mysqld.exe!?plugin_init##YAHPAHPAPADH#Z()
mysqld.exe!?init_net_server_extension##YAXPAVTHD###Z()
mysqld.exe!?win_main##YAHHPAPAD#Z()
mysqld.exe!?mysql_service##YAHPAX#Z()
mysqld.exe!strxnmov()
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlInitializeExceptionChain()
ntdll.dll!RtlInitializeExceptionChain()
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.
I've also come across this problem recently when I was trying to install XAMPP to my computer running Windows 10.
If you read the warnings that is given by the program you can see that it return a lot of errors regarding OS. Given "D:\win32-packages\build\src\storage\xtradb\os\os0file.cc" I'm assuming that your computer has several disks hence it's not C: drive.
You should try installing XAMPP on your C:/ drive along with the Windows system. This solved the problem for me, previously I had it on my E: drive and I was not able to run mysql, but Apache worked fine.
2LDR: INSTALL XAMPP to your C:/ drive along with your OS and return with feedback :)

Mysql server crash on start

Mysql server crash on start on my Ubuntu 12.04.2 server. Mysql just not starting. Not after reboot, not after service mysql start(it return start: Job failed to start).
Previously it worked fine, but at some point the server crashed and I was not able to run it.
/var/log/mysql/error.log:
151109 10:02:14 [Note] Plugin 'FEDERATED' is disabled.
151109 10:02:14 InnoDB: The InnoDB memory heap is disabled
151109 10:02:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151109 10:02:14 InnoDB: Compressed tables use zlib 1.2.3.4
151109 10:02:14 InnoDB: Initializing buffer pool, size = 128.0M
151109 10:02:14 InnoDB: Completed initialization of buffer pool
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
151109 10:02:15 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 76607...(I removed the part)...3c3f438045ca5727; asc v` E W1 9 - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? ! " # $ % & ' ( ) * + , _ # _ # jPs <?C E W';
InnoDB: End of page dump
151109 10:02:15 InnoDB: Page checksum 1986035693, prior-to-4.0.14-form checksum 3548252131
InnoDB: stored checksum 1986035693, prior-to-4.0.14-form stored checksum 1010779008
InnoDB: Page lsn 0 1170888497, low 4 bytes of lsn at page end 1170888487
InnoDB: Page number (if stored to page already) 5,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a transaction system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
151109 10:02:15 InnoDB: Assertion failure in thread 3065161472 in file buf0buf.c line 3629
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:02:15 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=16777216
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 = 346064 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb733d003]
/usr/sbin/mysqld(handle_fatal_signal+0x484)[0xb71e9f24]
[0xb6ea0400]
/usr/sbin/mysqld(+0x590e78)[0xb7453e78]
/usr/sbin/mysqld(+0x591852)[0xb7454852]
/usr/sbin/mysqld(+0x58109a)[0xb744409a]
/usr/sbin/mysqld(+0x54f75d)[0xb741275d]
/usr/sbin/mysqld(+0x551d09)[0xb7414d09]
/usr/sbin/mysqld(+0x53d5e0)[0xb74005e0]
/usr/sbin/mysqld(+0x501a22)[0xb73c4a22]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4e)[0xb71ec74e]
/usr/sbin/mysqld(+0x1fbd82)[0xb70bed82]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xbc3)[0xb70c2723]
/usr/sbin/mysqld(+0x16691a)[0xb702991a]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x66a)[0xb702d61a]
/usr/sbin/mysqld(main+0x27)[0xb7022d27]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb6b5f4d3]
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.

"ERROR 2013 (HY000): Lost connection to MySQL server during query" while dropping database

I have an empty database that I cannot drop. Initially, it contained a table that I couldn't SELECT from. So I DROP'ed all tables from that database and tried to DROP the database without success :
mysql> drop database my_database;
ERROR 2013 (HY000): Lost connection to MySQL server during query
Now I have an empty database that I cannot remove in my server.
I check the mysql error.log, here is the output :
130812 10:02:45 InnoDB: Assertion failure in thread 140409656780544 in file row0mysql.c line 3682
InnoDB: Failing assertion: table
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:02:45 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=16777216
read_buffer_size=131072
max_used_connections=3
max_threads=151
thread_count=3
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346685 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7fb3ad55d030
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 = 7fb3abb71e60 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7fb3ac1516b9]
/usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x7fb3ac039318]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fb3aab96cb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fb3aa1ff425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7fb3aa202b8b]
/usr/sbin/mysqld(+0x561acd)[0x7fb3ac192acd]
/usr/sbin/mysqld(+0x542c63)[0x7fb3ac173c63]
/usr/sbin/mysqld(+0x40837f)[0x7fb3ac03937f]
/usr/sbin/mysqld(_Z24plugin_foreach_with_maskP3THDPFcS0_P13st_plugin_intPvEijS3_+0x165)[0x7fb3abf4daa5]
/usr/sbin/mysqld(_Z11mysql_rm_dbP3THDPcbb+0x300)[0x7fb3abf23580]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x203c)[0x7fb3abf418ac]
/usr/sbin/mysqld(+0x31301e)[0x7fb3abf4401e]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19e7)[0x7fb3abf46247]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x105)[0x7fb3abfe0405]
/usr/sbin/mysqld(handle_one_connection+0x50)[0x7fb3abfe0520]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fb3aab8ee9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fb3aa2bcccd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fb388004b90): is an invalid pointer
Connection ID (thread ID): 59
Status: NOT_KILLED
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.
130812 10:02:45 [Note] Plugin 'FEDERATED' is disabled.
130812 10:02:45 InnoDB: The InnoDB memory heap is disabled
130812 10:02:45 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130812 10:02:45 InnoDB: Compressed tables use zlib 1.2.7
130812 10:02:45 InnoDB: Using Linux native AIO
130812 10:02:45 InnoDB: Initializing buffer pool, size = 128.0M
130812 10:02:45 InnoDB: Completed initialization of buffer pool
130812 10:02:45 InnoDB: highest supported file format is Barracuda.
130812 10:02:45 InnoDB: Waiting for the background threads to start
130812 10:02:46 InnoDB: 5.5.32 started; log sequence number 25852489043
130812 10:02:46 InnoDB: !!! innodb_force_recovery is set to 4 !!!
130812 10:02:46 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
130812 10:02:46 [Note] - '127.0.0.1' resolves to '127.0.0.1';
130812 10:02:46 [Note] Server socket created on IP: '127.0.0.1'.
130812 10:02:46 [Note] Event Scheduler: Loaded 0 events
130812 10:02:46 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
I tried to put the configuration innodb_force_recovery = 4 and restart MySQL but it had no effect at all.
Reinstalling the server is not an option here. It happened on many machines (2 Ubuntu and 2 CentOS), but I cannot reproduce the problem right now.
I believe it has to do with InnoDB table corruption. I too had a similar issue and was able to pinpoint it to a single table. I'm still in the process of correcting the issue through duplicating the table and removing the single record that is bad in my case.
This link helped me significantly:
Recovering InnoDB Table Corruption
Sorry for incomplete answer, but this helped me quite a bit once I found it.