Bug #16843 MySQL-Server dies if InnoDB-Buffer-Pool-Size grows up
Submitted: 27 Jan 2006 14:32 Modified: 28 Jan 2006 10:08
Reporter: Jens Schanz Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S2 (Serious)
Version:4.0.18 OS:Linux (SLES8)
Assigned to: Heikki Tuuri CPU Architecture:Any

[27 Jan 2006 14:32] Jens Schanz
Description:
060126 17:26:15  InnoDB: ERROR: over 9 / 10 of the buffer pool is occupied by
InnoDB: lock heaps or the adaptive hash index!
InnoDB: We intentionally generate a seg fault to print a stack trace
InnoDB: on Linux!
060126 17:26:15  InnoDB: Assertion failure in thread 61455 in file buf0lru.c line 234
InnoDB: Failing assertion: 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Send a detailed bug report to mysql@lists.mysql.com
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=67108864
read_buffer_size=4190208
max_used_connections=10
max_connections=450
threads_connected=8
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3750132 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x7c636e08
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=0xbfdddd98, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8071f44
0x82a0e38
0x81b12db
0x81a9865
0x81b4126
0x81b45c9
0x81a6fb8
0x816580e
0x8136f72
0x813b071
0x80cef57
0x80cf038
0x809fba5
0x809f269
0x809ef03
0x8096bd7
0x8095876
0x807e469
0x8080735
0x807be13
0x807b85e
0x807b088
0x829e5ec
0x82c7dea
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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 0x8803368 = insert into test.tempReceiptCoupon (receiptHeaderId, receiptCouponId, conditionDiscount)  select b.receiptHeaderId, b.receiptCouponId, sum(b.conditionDiscount)  from TaNBOreceiptHeader a, TaNBOreceiptPosition b  where a.receiptHeaderId = b.receiptHeaderId  and a.arrivalDate between '2005-12-01' and '2005-12-31'  and b.receiptCouponId is not NULL  and a.receiptStatusId = 2  and a.canceledReceiptHeaderId is NULL  and b.cancelationTypeId in (0,2)  and b.modificationTypeId in (0,2,3)  group by b.receiptHeaderId, b.receiptCouponId, b.receiptConditionId  order by a.receiptHeaderId
thd->thread_id=52
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 12292 stopped in file os0sync.c line 501

Number of processes running now: 0
060126 17:26:16  mysqld restarted
060126 17:26:19  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 277 3984910361
InnoDB: Doing recovery: scanned up to log sequence number 277 3984910361
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 607487, file name server214vx-bin.1003
InnoDB: Last MySQL binlog file position 0 6162072, file name /opt/mysql/archive/mysql_binlog.001
060126 17:26:20  InnoDB: Flushing modified pages from the buffer pool...
060126 17:26:21  InnoDB: Started

How to repeat:
Define buffer pool size to small value and run a large transaction which locks two or three tables

Suggested fix:
Maybee the queries who create this problem should be killed. Today, the server dies and will be restarted.
[28 Jan 2006 10:08] Heikki Tuuri
Jens,

this has already been fixed in 4.1.xx. If InnoDB notices that locks are exhausting the space in the buffer pool, it makes the query to fail with an error.

Regards,

Heikki