Description:
While running a test suite that does several concurrent inserts and updates, after uploading and updating about 3,7GB data mysqld hit this:
Actual crash:
080219 20:47:07 [Note] ./sql/mysqld: ready for connections.
Version: '5.1.24-maria-alpha-valgrind-max-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution
mysqld: ma_loghandler.c:2366: translog_buffer_flush: Assertion `buffer->file != ((void *)0)' failed.
080222 22:35:27 - mysqld got signal 6;
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=23
max_threads=151
threads_connected=22
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337706 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0xa96b2100
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=0xb19b2d58, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8231f6b
0xb7fc1410
0xb7df69a1
0xb7dee84b
0x84ee5d2
0x84f6f97
0x8508ee7
0x84e4ada
0x83237f5
0x822ad60
0x822af64
0x82bb64a
0x824815d
0x8248a43
0x8249c1d
0x824ac43
0x823a8d7
0xb7f86112
0xb7e8b48e
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.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 0xa8256690 is invalid pointer
thd->thread_id=1709
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.
----------------------
Resolved stack trace follows:
0x8231f6b handle_segfault + 595
0xb7fc1410 _end + -1357117192
0xb7df69a1 _end + -1358995831
0xb7dee84b _end + -1359028941
0x84ee5d2 translog_buffer_flush + 113
0x84f6f97 translog_flush + 2948
0x8508ee7 ma_commit + 185
0x84e4ada _ZN8ha_maria13external_lockEP3THDi + 454
0x83237f5 _ZN7handler16ha_external_lockEP3THDi + 121
0x822ad60 _Z15unlock_externalP3THDPP8st_tablej + 112
0x822af64 _Z19mysql_unlock_tablesP3THDP13st_mysql_lock + 62
0x82bb64a _Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_d
uplicatesb + 3318
0x824815d _Z21mysql_execute_commandP3THD + 29517
0x8248a43 _Z11mysql_parseP3THDPKcjPS2_ + 355
0x8249c1d _Z16dispatch_command19enum_server_commandP3THDPcj + 2953
0x824ac43 _Z10do_commandP3THD + 571
0x823a8d7 handle_one_connection + 769
0xb7f86112 _end + -1357359622
0xb7e8b48e _end + -1358386826
How to repeat:
This is not easily repeatable at the moment, because it took several days to complete this far. I can try to make a repeatable test case, but it is possible that you may find what is wrong with resolved stack trace and the actual assertion failure above alone.
