I have reported this before, but MySQL-Max-3.23.56-1 (official rpm's) is
repeatedly crashing.
Often when executing queries on an InnoDB table with about 1300 rows
that are similar to this:
select MEET, count(*)
from RATINGS_WHENU
where MEET in ('N','Y')
and SITE = '63'
group by MEET
I can run the query again and again, and cannot get it to crash myself,
but our applications run this query on regular occasion.
Below is output of some recent crashes this am.
Any help is appreciated. I reported this or atleast a very similar
problem before and I followed the advice to use the most recent MySQL
and to alter a few variables which did seem to help for a couple of
weeks atleast. Our db traffic really hasn't changed much since then so
I am flummoxed as to why now this would resurface.
Thanks,
Richard F. Rebel.
/usr/sbin/mysqld-max: ready for connections
030604 10:19:09 InnoDB: Assertion failure in thread 1319235 in file
mem0pool.c line 491
InnoDB: We intentionally generate a memory trap.
InnoDB: Send a detailed bug report to [EMAIL PROTECTED]
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
record_buffer=2093056
sort_buffer=2097144
max_used_connections=397
max_connections=2000
threads_connected=379
It is possible that mysqld could use up to
key_buffer_size + (record_buffer + sort_buffer)*max_connections =
3997872 K
bytes of memory
Hope that's ok, if not, decrease some variables in the equation
You seem to be running 32-bit Linux and have 379 concurrent connections.
If you have not changed STACK_SIZE in LinuxThreads and build the binary
yourself, LinuxThreads is quite likely to steal a part of global heap
for
the thread stack. Please read http://www.mysql.com/doc/L/i/Linux.html
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...
Stack range sanity check OK, backtrace follows:
0x806fcc4
0x82dad98
0x8289d65
0x8288852
0x81a149d
0x81a4fcb
0x80c2f73
0x80c5a33
0x80b48b6
0x8095979
0x8095633
0x808e337
0x8076b90
0x807acac
0x8075d45
0x80750e7
Stack trace seems successful - bottom reached
Please read http://www.mysql.com/doc/U/s/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 0x8f53d28 = select COMPLETE, count(*)
from RATINGS_WHENU
where COMPLETE in ('N','Y')
and SITE = '281'
group by COMPLETE
thd->thread_id=2374
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 2374 did to cause the crash. In some cases of
really
bad corruption, the values shown above may be invalid
The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash
Number of processes running now: 0
030604 10:19:10 mysqld restarted
Warning: Ignoring user change to 'mysql.prod' because the user was set
to 'mysql.prod' earlier on the command line
030604 10:19:15 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 15 1737508660
InnoDB: Doing recovery: scanned up to log sequence number 15 1738468019
030604 10:19:15 InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88
89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 1243390, file name
./silicon-bin.050
030604 10:19:23 InnoDB: Flushing modified pages from the buffer pool...
030604 10:19:28 InnoDB: Started
/usr/sbin/mysqld-max: ready for connections
InnoDB: Error: Removing element from mem pool free list 7 though the
InnoDB: element is not marked free! Dump of 100 bytes around element:
len 100; hex
544a5468652073697465206973206a75737420544f4f20534c4f572e204f74686572776973652c2077656c6c20646f6e652e81000000000000000000000020646566696e6974656c792062657474657220636f6d707574657220626f6f6b2073656c6563;
asc TJThe site is just TOO SLOW. Otherwise, well done............. definitely better
computer book selec;
030604 10:22:21 InnoDB: Assertion failure in thread 991475 in file
mem0pool.c line 372
InnoDB: We intentionally generate a memory trap.
InnoDB: Send a detailed bug report to [EMAIL PROTECTED]
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
record_buffer=2093056
sort_buffer=2097144
max_used_connections=385
max_connections=2000
threads_connected=382
It is possible that mysqld could use up to
key_buffer_size + (record_buffer + sort_buffer)*max_connections =
3997872 K
bytes of memory
Hope that's ok, if not, decrease some variables in the equation
You seem to be running 32-bit Linux and have 382 concurrent connections.
If you have not changed STACK_SIZE in LinuxThreads and build the binary
yourself, LinuxThreads is quite likely to steal a part of global heap
for
the thread stack. Please read http://www.mysql.com/doc/L/i/Linux.html
InnoDB: Thread 28680 stopped in file ../include/sync0sync.ic line 109
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...
Stack range sanity check OK, backtrace follows:
0x806fcc4
0x82dad98
0x8289821
0x8288463
0x81a18c0
0x81a4fcb
0x80c2f73
0x80c5a33
0x80b48b6
0x8095979
0x8095633
0x808e337
0x8076b90
0x807acac
0x8075d45
0x80750e7
Stack trace seems successful - bottom reached
Please read http://www.mysql.com/doc/U/s/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 0x59d064d0 is invalid pointer
thd->thread_id=1829
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 1829 did to cause the crash. In some cases of
really
bad corruption, the values shown above may be invalid
The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash
Number of processes running now: 0
030604 10:22:21 mysqld restarted
Warning: Ignoring user change to 'mysql.prod' because the user was set
to 'mysql.prod' earlier on the command line
030604 10:22:28 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 15 1738585273
InnoDB: Doing recovery: scanned up to log sequence number 15 1739131556
030604 10:22:29 InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88
89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 533746, file name
./silicon-bin.051
030604 10:22:37 InnoDB: Flushing modified pages from the buffer pool...
030604 10:22:41 InnoDB: Started
/usr/sbin/mysqld-max: ready for connections
InnoDB: Error: Freeing element to mem pool free list though the
InnoDB: element is marked free! Dump of 100 bytes around element:
len 100; hex
4d455468652073697465206973206a75737420544f4f20534c4f572e204f74686572776973652c2077656c6c20646f6e652e010100000000000018762d416f6d206e9268a520773073656c2e630032080000000000000000000000000000000000000000;
asc MEexellentte to shop!ere.delivery.wise, well done..........v-Aom n.h.
w0sel.c.2.....................;
030604 10:23:35 InnoDB: Assertion failure in thread 122911 in file
mem0pool.c line 477
InnoDB: We intentionally generate a memory trap.
InnoDB: Send a detailed bug report to [EMAIL PROTECTED]
InnoDB: Thread 1622413 stopped in file ha_innobase.cc line 2268
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
record_buffer=2093056
sort_buffer=2097144
max_used_connections=387
max_connections=2000
threads_connected=384
It is possible that mysqld could use up to
key_buffer_size + (record_buffer + sort_buffer)*max_connections =
3997872 K
bytes of memory
Hope that's ok, if not, decrease some variables in the equation
You seem to be running 32-bit Linux and have 384 concurrent connections.
If you have not changed STACK_SIZE in LinuxThreads and build the binary
yourself, LinuxThreads is quite likely to steal a part of global heap
for
the thread stack. Please read http://www.mysql.com/doc/L/i/Linux.html
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...
Stack range sanity check OK, backtrace follows:
0x806fcc4
0x82dad98
0x8289c48
0x8288852
0x81a149d
0x81a4fcb
0x80c2f73
0x80c5a33
0x80b48b6
0x8095979
0x8095633
0x808e337
0x8076b90
0x807acac
0x8075d45
0x80750e7
Stack trace seems successful - bottom reached
Please read http://www.mysql.com/doc/U/s/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 0x597cc1e8 is invalid pointer
thd->thread_id=724
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 724 did to cause the crash. In some cases of
really
bad corruption, the values shown above may be invalid
The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash
Number of processes running now: 0
030604 10:23:36 mysqld restarted
Warning: Ignoring user change to 'mysql.prod' because the user was set
to 'mysql.prod' earlier on the command line
030604 10:23:41 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 15 1739135310
InnoDB: Doing recovery: scanned up to log sequence number 15 1739304931
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: Trx id counter is 0 244945664
030604 10:23:42 InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88
89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx with id 0 244945376
InnoDB: Rolling back of trx id 0 244945376 completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Last MySQL binlog file position 0 159649, file name
./silicon-bin.052
030604 10:23:45 InnoDB: Flushing modified pages from the buffer pool...
030604 10:23:48 InnoDB: Started
/usr/sbin/mysqld-max: ready for connections
--
Richard F. Rebel
[EMAIL PROTECTED]
t. 212.239.0000
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
