MySQL Bugs: #15173: InnoDB: Rolling back trx and got signal 11

Bug #15173	InnoDB: Rolling back trx and got signal 11
Submitted:	23 Nov 2005 4:23	Modified:	16 Mar 2006 12:56
Reporter:	Tawatchai Doungbal	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	4.0.18 max log	OS:	Linux (RedHat9)
Assigned to:	Heikki Tuuri	CPU Architecture:	Any

Description:
051123 10:11:47  mysqld started
051123 10:11:50  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 15 2014435127
InnoDB: Doing recovery: scanned up to log sequence number 15 2016812155
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 23192 row operations to undo
InnoDB: Trx id counter is 0 206460672
051123 10:11:50  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 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: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx with id 0 206457813, 23192 rows to undo
InnoDB: Progress in percents: 1 2 3mysqld 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=209715200
read_buffer_size=1044480
max_used_connections=0
max_connections=300
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 817997 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8471608
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...
Bogus stack limit or frame pointer, fp=0xbfffcfdc, stack_bottom=0x685f7075, thread_stack=196608, aborting backtrace.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x6f72675f  is invalid pointer
thd->thread_id=0
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.
051123 10:11:52  mysqld ended

How to repeat:
copy record form table1 to table2 with different database
such as

begin;
insert into DB1.table1 select * from DB2.table2;

Suggested fix:
I did try to remove iblogfile but not work.

Comment : Records that I haved move about 1,000,000 to 1,800,000 records.

Tawatchai,

the database obviously is corrupt.

Please attach the FULL UNEDITED .err log of the mysqld server to this bug report.

You can try bringing up your database with the my.cnf option

innodb_force_recovery=4

Then dump all tables and recreate the whole InnoDB installation.

Regards,

Heikki

Note: do not ever remove ib_logfiles. Use the innodb_force_recovery option in problems to start up mysqld.

Regards,

Heikki

Please, send the full error log as Heikki asked you to.

thank you.

I did change my.cnf with innodb_force_recovery=3 and drop error-table.

Finally, the system bring up to work and completed.

Tawa,

please send the full .err log.

Heikki

IMPORTANT: Please, send the full error log as Heikki asked you to!

This file show contineusly 'first_errorlog.err'

Attachment: first_errorlog2.err (application/octet-stream, text), 198.82 KiB.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

This may have been a corrupt table. Hard to say anything without resolved stack traces.