Create table: CREATE TABLE `beta_parts_numbers` ( `ID` int(10) unsigned NOT NULL auto_increment, `ID_parts` int(10) unsigned NOT NULL, `consecutive_number` int(10) unsigned default NULL, `number_prefix` char(31) default NULL, `number_postfix` char(31) default NULL, `insert_date` datetime NOT NULL, `last_change` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, `ID_staff_change` int(10) unsigned default NULL, PRIMARY KEY (`ID`), KEY `ID_parts` (`ID_parts`), KEY `ID_staff_change` (`ID_staff_change`), CONSTRAINT `beta_parts_numbers_ID_parts` FOREIGN KEY (`ID_parts`) REFERENCES `beta_parts` (`ID`) ON DELETE CASCADE, CONSTRAINT `beta_parts_numbers_ID_staff_change` FOREIGN KEY (`ID_staff_change`) REFERENCES `beta_staff` (`ID`) ON DELETE SET NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 Query: mysql> insert into beta_parts_numbers SET ID_parts=0; ERROR 2013 (HY000): Lost connection to MySQL server during query Stacktrace: 0x818d0af handle_segfault + 653 0xb7e486c7 _end + -1351292713 0x8467c78 rec_get_offsets_func + 615 0x84697cf rec_print + 138 0x83b08fb row_ins_foreign_report_add_err + 701 0x83b2b1f row_ins_check_foreign_constraint + 2354 0x83b310d row_ins_check_foreign_constraints + 148 0x83b4e3b row_ins + 265 0x83b5188 row_ins_step + 82 0x83b69a3 row_insert_for_mysql + 546 0x82856c5 _ZN11ha_innobase9write_rowEPc + 659 0x82046c7 _Z12write_recordP3THDP8st_tableP12st_copy_info + 967 0x8205d80 _Z12mysql_insertP3THDP13st_table_listR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesb + 3176 0x81ac78a _Z21mysql_execute_commandP3THD + 22742 0x81b0df0 _Z11mysql_parseP3THDPcj + 1080 0x81b19fe _Z16dispatch_command19enum_server_commandP3THDPcj + 2944 0x81b2b5d _Z10do_commandP3THD + 261 0x81b36ed handle_one_connection + 2505 0xb7e42ae4 _end + -1351316236 0xb7ca43da _end + -1353013782 mysqld.err output: 051207 13:03:30InnoDB: Assertion failure in thread 180236 in file rem0rec.c line 339 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/mysql/en/Forcing_recovery.html InnoDB: about forcing recovery. 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=201326592 read_buffer_size=1044480 max_used_connections=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 401004 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8d91240 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=0x967319c8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x818d0af 0xb7e486c7 0x8467c78 0x84697cf 0x83b08fb 0x83b2b1f 0x83b310d 0x83b4e3b 0x83b5188 0x83b69a3 0x82856c5 0x82046c7 0x8205d80 0x81ac78a 0x81b0df0 0x81b19fe 0x81b2b5d 0x81b36ed 0xb7e42ae4 0xb7ca43da New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.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 0x8d8cb48 = insert into beta_parts_numbers SET ID_parts=0 thd->thread_id=16 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. InnoDB: Thread 196621 stopped in file row0sel.c line 2081 051207 13:03:39 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=medusa-bin' to avoid this problem. 051207 13:03:39 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... 051207 13:03:39 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 8 3939729867. InnoDB: Doing recovery: scanned up to log sequence number 8 3939745483 051207 13:03:39 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 11791, file name ./medusa-bin.000051 051207 13:03:40 InnoDB: Started; log sequence number 8 3939745483 051207 13:03:40 [Note] Recovering after a crash using medusa-bin 051207 13:03:40 [Note] Starting crash recovery... 051207 13:03:40 [Note] Crash recovery finished. 051207 13:03:40 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.16-debug-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Gentoo Linux mysql-5.0.16-r3