Am 17.10.2012 11:38, schrieb Hendrik Woltersdorf:
> after upgrading from version 7.1.18 to 7.2.8 we get regularly a crash
> in all systems under the conditions described in bugreport #65979:
> 09:38:47 UTC - 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
> or misconfigured. This error can also be caused by malfunctioning
> 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.
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 418037 K bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
> Thread pointer: 0x1ed3b260
> 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 = 496f3e98 thread_stack 0x40000
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort.
> Query (0): is an invalid pointer
> Connection ID (thread ID): 1
> Status: NOT_KILLED
> I can repduce this crash by doing a "replace into" statement into a
> table, where all columns ar part of the primary key.
> 'CREATE TABLE `sec_type` (
> `client_id` varchar(10) NOT NULL,
> `sec_type` varchar(10) NOT NULL,
> PRIMARY KEY (`client_id`,`sec_type`),
> KEY `SECTYPE` (`client_id`,`sec_type`)
> ) ENGINE=ndbcluster DEFAULT CHARSET=latin1'
> insert into sec_type values('1','TPIN');
> replace into sec_type values('1','TPIN');
> The "replace" crashes all SQL nodes in the cluster with activated
> binary logging.
> Usually we install the generic binaries package, but a test with RPMs
> showed the same crash.
> All application developers gave me their word, that they do never use
> this "replace". The general query log did not show any suspicious
> Any ideas, how to find the killer statement and/or how to solve this
> I do not want to downgrade to 7.1.* again.
For more tests I got the source code and patched it, to not crash at:
in ha_ndbcluster_binlog.cc by not filling the columns next_file and next_position in
ndb_binlog_index if first->next_master_log_file == NULL.
This works. During these tests I saw, that in the crash case nothing gets written to the
binary log. That makes sense, because nothing has changed eventually.
But what makes no sense to me is, that a row gets written to ndb_binlog_index when nothing
gets written to the binary log. That might explain, why input data is missing.
In the bug tracker bug #65979 is set to "Not a Bug". Is someone able to set the status to
"Is a Bug" or else?
(I can't find a button to do this.)
Tel. mobil: 015222999584