Bug #33768 slave crashes without a stack trace
Submitted: 9 Jan 2008 14:12 Modified: 31 Jan 2008 16:20
Reporter: Costin Grigoras Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Replication Severity:S1 (Critical)
Version:5.1.22 OS:Linux (SLC 4.6)
Assigned to: CPU Architecture:Any
Tags: crash, replication, slave

[9 Jan 2008 14:12] Costin Grigoras
Description:
The slave worked for a few minutes than crashed. Both master and slave are 5.1.22, compiled from source. error.log content is below.

If I look with mysqlbinlog mysqld-bin.000002 --start-position=9042099 there is nothing there:

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 9042099
# at 9042157
# at 9042316
# at 9042374
# at 9042541
# at 9042599
# at 9042759
# at 9042800
# at 9042898
# at 9042956
# at 9043127
# at 9043185
# at 9043350

  Going back byte by byte, the first one that doesn't give an error is @9042090:
ERROR: Error in Log_event::read_log_event(): 'Event too big', data_len: 1199883508, event_type: 32

  Please let me know what other info would be useful to you.

  Cheers,

.costin

080109 14:44:13 [Note] Slave SQL thread initialized, starting replication in log 'mysqld-bin.000002' at position 9042099, relay log '/home/mysql/ALICE/mysql
/mysqld-relay-bin.000006' position: 8594288
080109 14:44:13 - 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=536870912
read_buffer_size=520192
max_used_connections=0
max_threads=2000
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 67094584 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x973adc0
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=0x40a81ee8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x973adc0 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.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 (nil)  is invalid pointer
thd->thread_id=1
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.
080109 14:44:13 [Note] /opt/mysql/libexec/mysqld: Shutdown complete

How to repeat:
Don't know yet
[10 Jan 2008 12:11] Susanne Ebrecht
Many thanks for writing a bug report,
Please provide a test case here, with which we can try to reproduce your szenario and the issue.
[31 Jan 2008 16:20] Susanne Ebrecht
Many thanks for your feedback.

This sounds like this is a migration problem.

Please, make sure, that you followed the steps at our migration documentation:
http://dev.mysql.com/doc/refman/5.1/en/upgrading-from-5-0.html

Also from older versions of MySQL 5.1 to newer versions of MySQL 5.1, you have to make the upgrade steps, because MySQL 5.1 still not is a released version and sometimes, there were bigger changes.

I'll set this bug to "not a bug".

Please feel free to open it again, when you disagree with me and you have still issue after following upgrade documentation.

Many thanks for trusting MySQL.