Bug #48569 mysqld got exception 0xc0000005
Submitted: 5 Nov 2009 14:02 Modified: 21 Nov 2009 11:08
Reporter: Roland Volkmann Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: General Severity:S2 (Serious)
Version:5.1.40-community-log OS:Windows (2003 Server 32Bit)
Assigned to: CPU Architecture:Any
Tags: crash, exception, innodb, server

[5 Nov 2009 14:02] Roland Volkmann
Description:
After update from version 5.1.39 to 5.1.40 mysql server already crashed the second time. First crash on 2009-10-26:

091026  8:46:30 - mysqld got exception 0xc0000005 ;
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=16777216
read_buffer_size=4194304
max_used_connections=43
max_threads=100
threads_connected=12
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 836214 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x4639f5c0
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...
00404D7A    mysqld.exe!???
004E2D4C    mysqld.exe!?append@String@@QAE_NPBDI@Z()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 4666AFB0=SHOW INNODB STATUS
thd->thread_id=2364090
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
091026  8:51:32 [Note] C:\Programme\MySQL\MySQL Server 5.1\bin\mysqld: Normal shutdown

>> before restarting the server I lowered value "read_buffer_size". Today (2009-11-05) next crash with the new value:

091105 14:20:33 - mysqld got exception 0xc0000005 ;
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=16777216
read_buffer_size=1048576
max_used_connections=50
max_threads=100
threads_connected=28
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 529014 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x463b40f8
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...
00404CEA    mysqld.exe!???
004E2D4C    mysqld.exe!?append@String@@QAE_NPBDI@Z()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 4696F1F8=SHOW INNODB STATUS
thd->thread_id=4396477
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
091105 14:26:57 [Note] C:\Programme\MySQL\MySQL Server 5.1\bin\mysqld: Normal shutdown

>> the server is running Windows 2003 Server Standard Edition 32 Bit with 3 GB ECC-RAM (enough free RAM), all other Services running stable, HW-Check without errors. All our tables are INNODB. Relevant part of my.ini:

[mysqld]
port=3306
basedir="C:/Programme/MySQL/MySQL Server 5.1/"
tmpdir="C:/Programme/MySQL/MySQL Server 5.1/temp/" 
datadir="D:/MySQL Datafiles/"
default-character-set=latin1
default-collation=latin1_german2_ci
lc_time_names="de_DE"
default-storage-engine=INNODB
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ANSI"
event_scheduler=ON
max_connections=100
max_allowed_packet=16M
max_heap_table_size=64M
sort_buffer_size=4M
join_buffer_size=4M
read_buffer_size=1M
read_rnd_buffer_size=4M
query_cache_size=16M
query_cache_limit=1M
table_open_cache=800
tmp_table_size=64M
thread_cache_size=8

key_buffer_size=16M
myisam_sort_buffer_size=8M
myisam_max_sort_file_size=10G
myisam_max_extra_sort_file_size=10G

innodb_data_home_dir="D:/MySQL Datafiles/"
innodb_data_file_path=ibdata1:5G:autoextend
innodb_autoextend_increment=256
innodb_buffer_pool_size=1024M
innodb_additional_mem_pool_size=8M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=8M
innodb_log_file_size=256M
innodb_file_io_threads=10
innodb_thread_concurrency=0
innodb_lock_wait_timeout=3
innodb_support_xa=0
innodb_use_legacy_cardinality_algorithm=OFF

log-error
slow_query_log
long_query_time=5
log-output=FILE

How to repeat:
sorry, no idea.
[5 Nov 2009 14:53] Valeriy Kravchuk
Thank you for the problem report. How much RAM do you have on that box?
[5 Nov 2009 23:21] Roland Volkmann
The box is an "IBM eSever xSeries 225" Dual-XEON with 3 GB of ECC-DDR2-RAM (2x512MB + 2x1024MB). When looking into the windows task manager you will find normally around 800MB of free physical memory, process list shows 1.188.732 KB virtual and 1.176.368 KB physical memory used by mysqld.exe
[18 Nov 2009 19:22] Valeriy Kravchuk
Please, check if the same problem happens with 5.1.41.
[18 Nov 2009 20:00] Roland Volkmann
The database is running on version 5.1.41 for 6 hours now. During update I found Bug #48872. So lets see what happens if we have regular traffic from tomorrow on.
[21 Nov 2009 10:46] Valeriy Kravchuk
So, do you have the same problem with 5.1.41?
[21 Nov 2009 11:03] Roland Volkmann
It seems to be stable again with 5.1.41 even after some extra stress yesterday (I had MySQL Administrator's Health page open, polling status information every 1 second for 8 hours).
[21 Nov 2009 11:08] Valeriy Kravchuk
So, let's consider problem solved by 5.1.41 for now.