Bug #5688 Upgraded 4.1.5 Server seg faults
Submitted: 21 Sep 2004 21:31 Modified: 24 Sep 2004 7:35
Reporter: Nathaniel Blanchard Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:4.1.5 OS:Any (ALL)
Assigned to: Konstantin Osipov CPU Architecture:Any

[21 Sep 2004 21:31] Nathaniel Blanchard
Description:
Using the latest MySQL 4.1.5, something is causing it to crash.  Previously, we were running 4.1.4 both as the database and our client libs.  Upgrading the client libs to 4.1.5 and recompiling our application against a 4.1.4 database worked fine without any issues.  As soon as we moved the database to 4.1.5, the server seg faults when running various queries.

This happens on both windows and linux.

How to repeat:
040921 14:40:12  mysqld started
040921 14:40:13  InnoDB: Started; log sequence number 14 2587541413
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.5-gamma-log'  socket: '/tmp/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=1048576
read_buffer_size=131072
max_used_connections=2
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 = 538111 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8923210
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=0xbe5fea38, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80b4cb8
0x8330996
0x805d0b7
0x806db2e
0x806d15e
0x80e45c9
0x80e936a
0x8090b94
0x808e3bd
0x806ac6d
0x806d15e
0x80e45c9
0x80e936a
0x80ec441
0x80fd0e5
0x80c6b91
0x81057ad
0x81054b9
0x80c5872
0x80c53c6
0x80c4bbf
0x832e13f
0x835d3ba
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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 0x62721978  is invalid pointer
thd->thread_id=81
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
040921 16:53:23  mysqld restarted
040921 16:53:23  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040921 16:53:23  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 2607408856.
InnoDB: Doing recovery: scanned up to log sequence number 14 2612651520
InnoDB: Doing recovery: scanned up to log sequence number 14 2617894400
InnoDB: Doing recovery: scanned up to log sequence number 14 2623137280
InnoDB: Doing recovery: scanned up to log sequence number 14 2628380160
InnoDB: Doing recovery: scanned up to log sequence number 14 2633623040
InnoDB: Doing recovery: scanned up to log sequence number 14 2638865920
InnoDB: Doing recovery: scanned up to log sequence number 14 2644108800
InnoDB: Doing recovery: scanned up to log sequence number 14 2648611346
040921 16:53:25  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
040921 16:53:40  InnoDB: Flushing modified pages from the buffer pool...
040921 16:53:44  InnoDB: Started; log sequence number 14 2648611346
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.5-gamma-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
pure virtual method called
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=1048576
read_buffer_size=131072
max_used_connections=1
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 = 538111 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8902d10
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=0xbe7fe6e8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80b4cb8
0x8330996
0x8341711
0x8341b19
0x8338cdb
0x8338cfa
0x8338cbb
0x806dc39
0x806d15e
0x80e45c9
0x80e936a
0x8090b94
0x808e3bd
0x806ac6d
0x806d15e
0x80e45c9
0x80e936a
0x8090b94
0x808e3bd
0x806ac6d
0x806d15e
0x80e45c9
0x80e936a
0x80ec441
0x80fd0e5
0x80c6b91
0x81057ad
0x81054b9
0x80c5872
0x80c53c6
0x80c4bbf
0x832e13f
0x835d3ba
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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 0x8921228 = SELECT MIN(FirstDownloadDateTime) TrendDateTime, COUNT(SessionID) FROM ncftpd_Sessions WHERE SessionID IN (SELECT SessionID FROM ncftpd_Downloads WHERE  ( FileID  IN (SELECT FileID FROM ncftpd_FileID WHERE Filename LIKE '%t%') )  )  AND (FirstDownloadDate >= 2451149 AND FirstDownloadDate <= 2451179) GROUP BY FirstDownloadDate ORDER BY TrendDateTime
thd->thread_id=1
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
040921 16:54:50  mysqld restarted
040921 16:54:51  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040921 16:54:51  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 2649541378.
InnoDB: Doing recovery: scanned up to log sequence number 14 2654784000
InnoDB: Doing recovery: scanned up to log sequence number 14 2660026880
InnoDB: Doing recovery: scanned up to log sequence number 14 2661537229
040921 16:54:51  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
040921 16:54:56  InnoDB: Flushing modified pages from the buffer pool...
040921 16:54:57  InnoDB: Started; log sequence number 14 2661537229
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.5-gamma-log'  socket: '/tmp/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=1048576
read_buffer_size=131072
max_used_connections=1
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 = 538111 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8902d10
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=0xbe7fea38, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80b4cb8
0x8330996
0x805d0b7
0x806db2e
0x806d15e
0x80e45c9
0x80e936a
0x8090b94
0x808e3bd
0x806ac6d
0x806d15e
0x80e45c9
0x80e936a
0x80ec441
0x80fd0e5
0x80c6b91
0x81057ad
0x81054b9
0x80c5872
0x80c53c6
0x80c4bbf
0x832e13f
0x835d3ba
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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 0x898d9f8 = SELECT MIN(VisitDateTime) TrendDateTime, COUNT(ViewID) FROM ncsa_Views WHERE  ( DirectoryID  IN (SELECT DirectoryID FROM ncsa_DirectoryID WHERE Directory LIKE '%/eval/%') )  AND (VisitDate >= 2451392 AND VisitDate <= 2451422) GROUP BY VisitDate ORDER BY TrendDateTime
thd->thread_id=1
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
040921 16:55:20  mysqld restarted
040921 16:55:20  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040921 16:55:20  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 2661537387.
InnoDB: Doing recovery: scanned up to log sequence number 14 2666780160
InnoDB: Doing recovery: scanned up to log sequence number 14 2666988565
040921 16:55:20  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
040921 16:55:23  InnoDB: Flushing modified pages from the buffer pool...
040921 16:55:23  InnoDB: Started; log sequence number 14 2666988565
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.5-gamma-log'  socket: '/tmp/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=1048576
read_buffer_size=131072
max_used_connections=1
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 = 538111 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8902d10
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=0xbe7fea38, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80b4cb8
0x8330996
0x805d0b7
0x806db2e
0x806d15e
0x80e45c9
0x80e936a
0x8090b94
0x808e3bd
0x806ac6d
0x806d15e
0x80e45c9
0x80e936a
0x80ec441
0x80fd0e5
0x80c6b91
0x81057ad
0x81054b9
0x80c5872
0x80c53c6
0x80c4bbf
0x832e13f
0x835d3ba
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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 0x899b120 = SELECT MIN(VisitDateTime) TrendDateTime, COUNT(ViewID) FROM ncsa_resume_Views WHERE  ( DirectoryID  IN (SELECT DirectoryID FROM ncsa_resume_DirectoryID WHERE Directory LIKE '%/eval/%') )  AND (VisitDate >= 2451392 AND VisitDate <= 2451422) GROUP BY VisitDate ORDER BY TrendDateTime
thd->thread_id=1
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
040921 16:55:43  mysqld restarted
040921 16:55:44  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040921 16:55:44  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 2666988585.
InnoDB: Doing recovery: scanned up to log sequence number 14 2671414743
040921 16:55:44  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
040921 16:55:46  InnoDB: Flushing modified pages from the buffer pool...
040921 16:55:47  InnoDB: Started; log sequence number 14 2671414743
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.5-gamma-log'  socket: '/tmp/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=1048576
read_buffer_size=131072
max_used_connections=1
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 = 538111 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8902d10
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=0xbe7fe9a8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80b4cb8
0x8330996
0x805d0b7
0x806db2e
0x806d15e
0x80e45c9
0x80e936a
0x8090b94
0x808e3bd
0x806ac6d
0x805d0ba
0x806d15e
0x80e45c9
0x80e936a
0x80ec441
0x80fd0e5
0x80c6b91
0x81057ad
0x81054b9
0x80c5872
0x80c53c6
0x80c4bbf
0x832e13f
0x835d3ba
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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 0x896aea8 = SELECT MIN(FirstViewDateTime) TrendDateTime, COUNT(SessionID) FROM pncsa_Sessions WHERE  ( EndingPageID NOT IN (SELECT PageID FROM pncsa_PageID WHERE Page LIKE '%.com%') )  AND (FirstViewDate >= 2451392 AND FirstViewDate <= 2451422) GROUP BY FirstViewDate ORDER BY TrendDateTime
thd->thread_id=1
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
040921 16:56:15  mysqld restarted
040921 16:56:15  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040921 16:56:15  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 2671414947.
InnoDB: Doing recovery: scanned up to log sequence number 14 2675907846
040921 16:56:16  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
040921 16:56:18  InnoDB: Flushing modified pages from the buffer pool...
040921 16:56:19  InnoDB: Started; log sequence number 14 2675907846
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.5-gamma-log'  socket: '/tmp/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=1048576
read_buffer_size=131072
max_used_connections=1
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 = 538111 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8902d10
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=0xbe7fe9a8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80b4cb8
0x8330996
0x805d0b7
0x806db2e
0x806d15e
0x80e45c9
0x80e936a
0x8090b94
0x808e3bd
0x806ac6d
0x805d0ba
0x806d15e
0x80e45c9
0x80e936a
0x80ec441
0x80fd0e5
0x80c6b91
0x81057ad
0x81054b9
0x80c5872
0x80c53c6
0x80c4bbf
0x832e13f
0x835d3ba
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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 0x8933e20 = SELECT MIN(FirstViewDateTime) TrendDateTime, COUNT(SessionID) FROM pncsa_resume_Sessions WHERE  ( EndingPageID NOT IN (SELECT PageID FROM pncsa_resume_PageID WHERE Page LIKE '%.com%') )  AND (FirstViewDate >= 2451392 AND FirstViewDate <= 2451422) GROUP BY FirstViewDate ORDER BY TrendDateTime
thd->thread_id=1
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
040921 16:56:26  mysqld restarted
040921 16:56:26  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040921 16:56:26  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 2675907846.
InnoDB: Doing recovery: scanned up to log sequence number 14 2676812680
040921 16:56:26  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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
040921 16:56:28  InnoDB: Flushing modified pages from the buffer pool...
040921 16:56:28  InnoDB: Started; log sequence number 14 2676812680
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.5-gamma-log'  socket: '/tmp/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=1048576
read_buffer_size=131072
max_used_connections=1
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 = 538111 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8902d10
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=0xbe7fea38, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80b4cb8
0x8330996
0x805d0b7
0x806db2e
0x806d15e
0x80e45c9
0x80e936a
0x8090b94
0x808e3bd
0x806ac6d
0x806d15e
0x80e45c9
0x80e936a
0x80ec441
0x80fd0e5
0x80c6b91
0x81057ad
0x81054b9
0x80c5872
0x80c53c6
0x80c4bbf
0x832e13f
0x835d3ba
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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 0x8945650 = SELECT MIN(SessionDateTime) TrendDateTime, COUNT(DownloadID) FROM real_Downloads WHERE  ( ClipID  IN (SELECT ClipID FROM real_ClipID WHERE Clip LIKE '/summit/%') )  AND (SessionDate >= 2451331 AND SessionDate <= 2451360) GROUP BY SessionDate ORDER BY TrendDateTime
thd->thread_id=1
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
040921 16:57:04  mysqld restarted
040921 16:57:04  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040921 16:57:04  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 2676812980.
InnoDB: Doing recovery: scanned up to log sequence number 14 2681821720
040921 16:57:04  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
040921 16:57:07  InnoDB: Flushing modified pages from the buffer pool...
040921 16:57:07  InnoDB: Started; log sequence number 14 2681821720
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.5-gamma-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
[22 Sep 2004 13:52] Nathaniel Blanchard
After further investigation, I was able to track down exactly what (at least the first occurance) was causing the server to crash.  Here is a test program that causes the issue.

    MYSQL mysql;
    long lCount;
    unsigned long length[2];
    my_bool       is_null[2];
    MYSQL_STMT    *stmt;
    MYSQL_BIND    bind[2];
    MYSQL_TIME    udtDateTime;

    #define SELECT_QUERY "SELECT MIN(FirstDownloadDateTime) TrendDateTime, COUNT(SessionID) " \
                         "FROM mcluster_Sessions " \
                         "WHERE  ( StartingClipID  IN (SELECT ClipID FROM mcluster_ClipID WHERE Clip LIKE '/welcome%') )  AND (FirstDownloadDate >= 2451911 AND FirstDownloadDate <= 2451941) " \
                         "GROUP BY FirstDownloadDate " \
                         "ORDER BY TrendDateTime "

    mysql_init(&mysql);
    mysql_real_connect(&mysql,"nate","nate","nate","nate",0,NULL,0);

    stmt = mysql_stmt_init(&mysql);

    mysql_stmt_prepare(stmt, SELECT_QUERY, strlen(SELECT_QUERY) );

    mysql_stmt_execute(stmt);
  

The server will crash on the mysql_stmt_execute line.

The show create table for mcluster_Sessions is:

| mcluster_Sessions |CREATE TABLE `mcluster_sessions` (
  `SessionID` int(11) NOT NULL default '0',
  `Downloads` int(11) NOT NULL default '0',
  `LastDownloadID` int(11) NOT NULL default '0',
  `FirstDownloadDate` int(11) NOT NULL default '0',
  `FirstDownloadDOW` int(11) NOT NULL default '0',
  `LastDownloadDate` int(11) NOT NULL default '0',
  `LastDownloadTime` int(11) NOT NULL default '0',
  `Duration` int(11) NOT NULL default '0',
  `HostID` int(11) NOT NULL default '0',
  `DomainID` int(11) NOT NULL default '0',
  `PlayerID` int(11) NOT NULL default '0',
  `PlatformID` int(11) NOT NULL default '0',
  `PlayerBreakdownID` int(11) NOT NULL default '0',
  `StartingClipID` int(11) NOT NULL default '0',
  `EndingClipID` int(11) NOT NULL default '0',
  `UserID` int(11) NOT NULL default '0',
  `DepartmentID` int(11) NOT NULL default '0',
  `FirstDownloadDateTime` datetime NOT NULL default '0000-00-00 00:00:00',
  `FirstDownloadHour` int(11) NOT NULL default '0',
  `SessionLength` int(11) NOT NULL default '0',
  UNIQUE KEY `mcluster_Se_SessionID` (`SessionID`),
  KEY `mcluster_Se_FDDateIdx` (`FirstDownloadDate`,`FirstDownloadHour`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin |
[22 Sep 2004 13:54] Nathaniel Blanchard
| mcluster_ClipID | CREATE TABLE `mcluster_clipid` (
  `ClipID` int(11) NOT NULL default '0',
  `Clip` blob NOT NULL,
  UNIQUE KEY `mcluster_CID_CIDIdx` (`ClipID`,`Clip`(255)),
  UNIQUE KEY `mcluster_CID_CIdx` (`Clip`(255),`ClipID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin |
[22 Sep 2004 15:56] Konstantin Osipov
The test case in SQL syntax for prepared statements:
drop table mcluster_sessions, mcluster_clipid;
CREATE TABLE `mcluster_sessions` (
  `SessionID` int(11) NOT NULL default '0',
  `Downloads` int(11) NOT NULL default '0',
  `LastDownloadID` int(11) NOT NULL default '0',
  `FirstDownloadDate` int(11) NOT NULL default '0',
  `FirstDownloadDOW` int(11) NOT NULL default '0',
  `LastDownloadDate` int(11) NOT NULL default '0',
  `LastDownloadTime` int(11) NOT NULL default '0',
  `Duration` int(11) NOT NULL default '0',
  `HostID` int(11) NOT NULL default '0',
  `DomainID` int(11) NOT NULL default '0',
  `PlayerID` int(11) NOT NULL default '0',
  `PlatformID` int(11) NOT NULL default '0',
  `PlayerBreakdownID` int(11) NOT NULL default '0',
  `StartingClipID` int(11) NOT NULL default '0',
  `EndingClipID` int(11) NOT NULL default '0',
  `UserID` int(11) NOT NULL default '0',
  `DepartmentID` int(11) NOT NULL default '0',
  `FirstDownloadDateTime` datetime NOT NULL default '0000-00-00 00:00:00',
  `FirstDownloadHour` int(11) NOT NULL default '0',
  `SessionLength` int(11) NOT NULL default '0',
  UNIQUE KEY `mcluster_Se_SessionID` (`SessionID`),
  KEY `mcluster_Se_FDDateIdx` (`FirstDownloadDate`,`FirstDownloadHour`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin;

CREATE TABLE `mcluster_clipid` (
  `ClipID` int(11) NOT NULL default '0',
  `Clip` blob NOT NULL,
  UNIQUE KEY `mcluster_CID_CIDIdx` (`ClipID`,`Clip`(255)),
  UNIQUE KEY `mcluster_CID_CIdx` (`Clip`(255),`ClipID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin;

prepare stmt from "SELECT MIN(FirstDownloadDateTime) TrendDateTime, COUNT(SessionID) FROM mcluster_sessions WHERE  ( StartingClipID  IN (SELECT ClipID FROM
mcluster_clipid WHERE Clip LIKE '/welcome%') )  AND
(FirstDownloadDate >= 2451911 AND FirstDownloadDate <= 2451941) GROUP BY FirstDownloadDate ORDER BY TrendDateTime" ;

execute stmt;
[22 Sep 2004 15:57] Konstantin Osipov
Direct execution works OK
[24 Sep 2004 7:35] Konstantin Osipov
Fixed in 4.1.6:
Subject: bk commit - 4.1 tree (konstantin:1.2029) BUG#5688

ChangeSet
  1.2029 04/09/23 18:01:55 konstantin@mysql.com +3 -0
  A fix and test case for bug#5688 "Upgraded 4.1.5 Server seg faults"