I have opened a bug about this issue: http://bugs.mysql.com/bug.php?id=44914
Joel On Tue, May 12, 2009 at 10:55 PM, Joel Heenan <jo...@planetjoel.com> wrote: > Mysql List, > > I have a crash that has occured a number of times on a production CentOS > 4.4 machine. It occurs when using a product called Interspire Email Marketer > and doing an import of some 30,000 email addresses. Unfortunately, I have > not been able to reproduce the crash myself (I have tried numerous times). > > MySQL is version 4.1.22, latest for this version of CentOS. > > Should I open a bug report about this? Since it is production I can't do > too much on the host itself and I have limited ability to reproduce. > > Here is what the crash looks like: > > """ > Version: '4.1.22' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source > distribution > 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=402653184 > read_buffer_size=1044480 > max_used_connections=82 > max_connections=500 > threads_connected=44 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = > 1927212 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x950dc9c8 > 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=0x961626b4, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x8139eec > 0x4f6e67 > 0x831b884 > 0x81c22a7 > 0x81c3150 > 0x81b5f53 > 0x814f934 > 0x8151b3c > 0x815255a > 0x8152db5 > 0x815375b > 0x4f5371 > 0x3f5ffe > New value of fp=(nil) failed sanity check, terminating stack trace! > Please read http://dev.mysql.com/doc/mysql/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 0x9c20480 = SAVEPOINT interspire4a00f4b153ccf > thd->thread_id=108208 > 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. > > Number of processes running now: 0 > 090506 11:23:45 mysqld restarted > """ > > Here is what the /etc/my.cnf file looks like: > > """ > [mysqld] > datadir=/var/lib/mysql > socket=/var/lib/mysql/mysql.sock > old_passwords=1 > back_log = 75 > skip-innodb > max_connections = 500 > key_buffer = 384M > myisam_sort_buffer_size = 64M > join_buffer_size = 1M > read_buffer_size = 1M > sort_buffer_size = 2M > table_cache = 1800 > thread_cache_size = 384 > wait_timeout = 7200 > connect_timeout = 10 > tmp_table_size = 64M > max_heap_table_size = 64M > max_allowed_packet = 64M > max_connect_errors = 1000 > read_rnd_buffer_size = 524288 > bulk_insert_buffer_size = 8M > query_cache_limit = 4M > query_cache_size =128M > query_cache_type = 1 > query_prealloc_size = 65536 > query_alloc_block_size = 131072 > default-storage-engine = MyISAM > > [mysql.server] > user=mysql > basedir=/var/lib > > [mysqld_safe] > err-log=/var/log/mysqld.log > pid-file=/var/run/mysqld/mysqld.pid > nice = -5 > open_files_limit = 8192 > > [myisamchk] > tmpdir=/home/mysqltmp > key_buffer = 64M > sort_buffer = 64M > read_buffer = 16M > write_buffer = 16M > > [mysqldump] > quick > max_allowed_packet = 16M > """ > > Thanks > > Joel >
