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