| Bug #17674 | Crashing mem leak after optimize (Assertion failure in file row0sel.c line 2840) | ||
|---|---|---|---|
| Submitted: | 23 Feb 2006 17:21 | Modified: | 20 Nov 2011 8:34 |
| Reporter: | D O | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
| Version: | 4.1.7, 5.0 | OS: | Any (SunOS 5.9) |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
[23 Feb 2006 17:21]
D O
[23 Feb 2006 22:38]
Heikki Tuuri
Hi! Your MySQL version is quite old. Does the problem persist if you upgrade to 4.1.18? Regards, Heikki
[16 Mar 2006 14:24]
D O
This also happens in 5.0. If the optimize is turned off, and the other processes continue, the db does not crash. Also, note, there is plenty of memory and swap available when it crashes. Here is the output from the error log for 5.0: 060313 3:17:46 InnoDB: Error: cannot allocate 576 bytes of InnoDB: memory with malloc! Total allocated memory InnoDB: by InnoDB 3110199140 bytes. Operating system errno: 11 InnoDB: Check if you should increase the swap file or InnoDB: ulimits of your operating system. InnoDB: On FreeBSD check you have compiled the OS with InnoDB: a big enough maximum process size. InnoDB: Note that in most 32-bit computers the process InnoDB: memory space is limited to 2 GB or 4 GB. InnoDB: We keep retrying the allocation for 60 seconds... 060313 3:18:47 InnoDB: We now intentionally generate a seg fault so that InnoDB: on Linux we get a stack trace. 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=8388600 read_buffer_size=131072 max_used_connections=4 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. 060313 03:18:50 mysqld restarted
[16 Mar 2006 14:26]
D O
This is the 5.0 version information from the log: InnoDB: Progress in percents: 1060313 3:20:46 InnoDB: Started; log sequence number 30 3593718320 060313 3:20:46 [Note] /mysqldata/mysql-standard-5.0.18-solaris10-i386/bin/mysqld: ready for connections. Version: '5.0.18-standard' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL)
[16 Mar 2006 14:35]
Heikki Tuuri
Hi! InnoDB has allocated 3,110,199,140 bytes of memory. What is your my.cnf like? What is your OS/hardware? Regards, Heikki
[16 Mar 2006 16:49]
Heikki Tuuri
Ok, you have only 1.5 GB of buffer pool, but InnoDB says it has allocated 3 GB of memory! Can you post several SHOW INNODB STATUS\G during the optimize, so that we would see why InnoDB has allocated 1.5 GB more memory? Regards, Heikki
[20 Mar 2006 20:53]
Heikki Tuuri
Kevin, you can also send files to heikki.tuuri@oracle.com Regards, Heikki
[21 Mar 2006 7:58]
Marko Mäkelä
Fix memory leak in row_ins_duplicate_error_in_clust()
Attachment: bug17674.patch (text/x-patch), 607 bytes.
[21 Mar 2006 8:01]
Marko Mäkelä
There is a memory leak in MySQL/InnoDB 5.0.3 and later that has nothing to do with the original bug reported for MySQL/InnoDB 4.1.7. I attached a patch to the "Files" section of this bug report. The memory leak should only manifest itself with tables having more than 90 columns.
[21 Mar 2006 8:15]
Heikki Tuuri
I filed http://bugs.mysql.com/bug.php?id=18384 about the memory leak bug.
[29 Mar 2006 11:50]
Heikki Tuuri
When 5.0.20 comes out, please test if the original problem of 4.1.7, the assertion failure, still happens.
It was probably the assertion below (ut_error) that failed. I have no idea what could cause that problem.
trx->op_info = "fetching rows";
if (prebuilt->n_rows_fetched == 0) {
prebuilt->fetch_direction = direction;
}
if (direction != prebuilt->fetch_direction) {
if (prebuilt->n_fetch_cached > 0) {
ut_error;
/* TODO: scrollable cursor: restore cursor to
the place of the latest returned row,
or better: prevent caching for a scroll
cursor! */
}
[29 Apr 2006 23:00]
Bugs System
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".
