Message-ID: <4248AEA8.2010902@presence-pc.com> Date: Tue, 29 Mar 2005 01:26:00 +0000 From: Jocelyn Fournier User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "C. Tate Baumrucker" CC: internal@lists.mysql.com Subject: Re: Mysql 4.1.10 on Linux 2.4.9-e.59smp crash (UNCLASSIFIED) References: <200503282228.j2SMS7OB042480@rt1solut.iserver.net> In-Reply-To: <200503282228.j2SMS7OB042480@rt1solut.iserver.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, This crash seems to occur when mysql tries to write in the binlog the DROP /*!40005 TEMPORARY */ TABLE IF EXISTS ... query which is issued when the temporary tables are automatically destroyed when the current thread is ending. Question for internal : Just curious, is it possible to have a thd containing both user temporary tables and "internal" temporary tables ? Because in this case in the close_temporary_tables function, found_user_tables will be set to 1 and the DROP /*!40005 TEMPORARY */ TABLE IF EXISTS statement will be written to the binlog with the internal temp table name. Thanks ! Jocelyn C. Tate Baumrucker wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Implemented latest 4.1.10a-standard-log binary version and saw another crash > w/in about 3 hrs. Here's the log: > > 050328 15:39:35 mysqld started > 050328 15:39:36 InnoDB: Started; log sequence number 15 2379024139 > /data/mysql/bin/mysqld: ready for connections. > Version: '4.1.10a-standard-log' socket: '/tmp/mysql.sock' port: 3306 > MySQL Community Edition - Standard (GPL) > 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=2093056 > max_used_connections=6 > max_connections=100 > threads_connected=3 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = > 802415 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x96225e90 > 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=0xbfe7f458, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x808b193 > 0x82debe8 > 0x80dbbf8 > 0x80b3caf > 0x8081c2f > 0x808ad8b > 0x8098c56 > 0x82dc39c > 0x8305d2a > 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 (nil) is invalid pointer > thd->thread_id=3549 > 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 > 050328 17:22:04 mysqld restarted > 050328 17:22: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... > 050328 17:22:04 InnoDB: Starting log scan based on checkpoint at > InnoDB: log sequence number 15 2433246331. > InnoDB: Doing recovery: scanned up to log sequence number 15 2435610788 > 050328 17:22:04 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 > InnoDB: Last MySQL binlog file position 0 10782286, file name > ./performdb-1-bin.000111 > 050328 17:22:06 InnoDB: Flushing modified pages from the buffer pool... > 050328 17:22:06 InnoDB: Started; log sequence number 15 2435610788 > /data/mysql/bin/mysqld: ready for connections. > Version: '4.1.10a-standard-log' socket: '/tmp/mysql.sock' port: 3306 > MySQL Community Edition - Standard (GPL) > > > And the stack trace: > > 0x808b193 mysql_unlock_read_tables__FP3THDP13st_mysql_lock + 131 > 0x82debe8 gbksortorder + 8 > 0x80dbbf8 mysql_prepare_update__FP3THDP13st_table_listT1PP4ItemUiP8st_order > + 248 > 0x80b3caf yyparse__FPv + 59439 > 0x8081c2f sql_type__C10Field_geomR6String + 367 > 0x808ad8b mysql_errno_to_sqlstate + 43 > 0x8098c56 __static_initialization_and_destruction_0 + 5974 > 0x82dc39c my_strntol_8bit + 172 > 0x8305d2a canonicalize + 530 > > This one looks a bit different that the last ... > Tate > > -----Original Message----- > From: Baumrucker, Christopher T Mr ITA-IC/Lockheed Martin > [mailto:Christopher.Baumrucker@hqda.army.mil] > Sent: Monday, March 28, 2005 3:22 PM > To: 'mysql@lists.mysql.com' > Subject: Mysql 4.1.10 on Linux 2.4.9-e.59smp crash (UNCLASSIFIED) > > Classification: UNCLASSIFIED > Caveats: NONE > > > > All, > Having stability issues w/ Mysql 4.1.10 (innodb) on RH Linux 2.4.9-e.59smp > running AS 2.1. DB crashes randomly during execution of various SQL code > (all using user variables and temporarly tables and mostly simple selects, > inserts, joins, etc.). > > Using source-compiled binaries (./configure --prefix /data/mysql-4.1.10 > --with-extra-charsets=complex --enable-thread-safe-client > --enable-local-infile --enable-assembler --disable-shared > --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static). > > Database crashes about 3-5 times a day and usually recovers, but sometimes > dies with: > > [ERROR] Can't start server: Bind on TCP/IP port: Address already in use > [ERROR] Do you already have another mysqld server running on port: 3306 ? > [ERROR] Aborting > > relevant log is: > > 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=2093056 > max_used_connections=3 > max_connections=100 > threads_connected=2 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = > 802415 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x952cd40 > 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=0xbe3ff328, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x808ed97 > 0x82f348a > 0x80e1a59 > 0x80b87b8 > 0x808517a > 0x808e977 > 0x809c2d0 > 0x82f0c27 > 0x831fc9a > New value of fp=(nil) failed sanity check, terminating stack trace! > Please read HYPERLINK > http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html > 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 (nil) is invalid pointer > thd->thread_id=18 > The manual page at HYPERLINK http://www.mysql.com/doc/en/Crashing.html > 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 > 050328 15:07:27 mysqld restarted > 050328 15:07:28 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... > 050328 15:07:28 InnoDB: Starting log scan based on checkpoint at > InnoDB: log sequence number 15 2363300476. > InnoDB: Doing recovery: scanned up to log sequence number 15 2363307777 > 050328 15:07:28 InnoDB: Starting an apply batch of log records to the > database... > InnoDB: Progress in percents: 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 90221, file name > ./performdb-1-bin.000107 > 050328 15:07:29 InnoDB: Flushing modified pages from the buffer pool... > 050328 15:07:29 InnoDB: Started; log sequence number 15 2363307777 > /data/mysql-4.1.10/libexec/mysqld: ready for connections. > Version: '4.1.10-log' socket: '/tmp/mysql.sock' port: 3306 Source > distribution > > Performed stack trace on all recent crashes with same results for each: > > 0x808ed97 handle_segfault + 423 > 0x82f348a pthread_sighandler + 162 > 0x80e1a59 write__9MYSQL_LOGP9Log_event + 1817 > 0x80b87b8 close_temporary_tables__FP3THD + 248 > 0x808517a cleanup__3THD + 106 > 0x808e977 end_thread__FP3THDb + 23 > 0x809c2d0 handle_one_connection + 928 > 0x82f0c27 pthread_start_thread + 171 > 0x831fc9a thread_start + 4 > > Anyone have an idea as the the meaning of the trace? > Any help greatly appreciated. What other information can I provide? > Thinking of trying standard binaries .... > Thanks, > Tate > > > Classification: UNCLASSIFIED > Caveats: NONE > > Classification: UNCLASSIFIED > Caveats: NONE > > > >