Hi. There were several posts in list like yours.
Do you use InnoDB tables? Try to increase values of key_buffer_size, read_buffer_size and so on. Ugo Bellavance <[EMAIL PROTECTED]> wrote: > Hi, > > I've upgraded one of my servers (test) to 4.1.7 this week, all went ok. > Now I'm trying to upgrade another server (production) from 4.1.3 to > 4.1.7 and I'm having serious problems. I tried 4.1.6 as well, same problem. > > OS: Tao Linux (Red Hat Enterprise Linux 3.0 clone). > > First, since I couldn't find a procedure saying how to upgrade a > binary distribution, here is what I do. > > -Stop MySQL > -Downoad the tarball in /usr/local/. > -Check the md5 > -untar the tarball > -copy the content of the data directory of old version into new > version's data directory. > -fix up the permissions like described in the INSTALL-BINARY file included > -delete the /usr/local/mysql symlink and re-creating another one > pointing to the new version. > -Start MySQL > -Test > > Here is the problem: After this procedure, I connect with a mysql > client, use db, and then when I run a command like a select or update, > the server crashes, giving me those errors on the client: > > ERROR 2013: Lost connection to MySQL server during query > > Or: > > ERROR 2006: MySQL server has gone away > No connection. Trying to reconnect... > Connection id: 1 > Current database: db > > When I go to the error log, here is what I got: > > 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=16384 > read_buffer_size=258048 > 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 > = 31615 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x8908e40 > 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=0xbfe7eca8, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x808af93 > 0x82d6de8 > 0x80c00bf > 0x80bdeee > 0x80ba6e9 > 0x80bcd51 > 0x80b9de6 > 0x809a1dd > 0x809e6e9 > 0x8098def > 0x8098778 > 0x8097eb7 > 0x82d459c > 0x82fdf1a > 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 0x890f370 = SELECT * FROM `ville` > 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. > > ====================================== > > When resolving the stack trace, I get this: > > /usr/local/mysql/bin/resolve_stack_dump -s ./symbols -n ./stack > 0x808af93 handle_segfault + 423 > 0x82d6de8 pthread_sighandler + 184 > 0x80c00bf get_best_combination__FP4JOIN + 147 > 0x80bdeee > make_join_statistics__FP4JOINP13st_table_listP4ItemP16st_dynamic_array + > 4206 > 0x80ba6e9 optimize__4JOIN + 457 > 0x80bcd51 > mysql_select__FP3THDPPP4ItemP13st_table_listUiRt4List1Z4ItemP4ItemUiP8st_orderT7T5T7UlP13select_resultP18st_select_lex_unitP13s > > + 745 > 0x80b9de6 handle_select__FP3THDP6st_lexP13select_result + 150 > 0x809a1dd mysql_execute_command__FP3THD + 1241 > 0x809e6e9 mysql_parse__FP3THDPcUi + 169 > 0x8098def dispatch_command__F19enum_server_commandP3THDPcUi + 1643 > 0x8098778 do_command__FP3THD + 188 > 0x8097eb7 handle_one_connection + 615 > 0x82d459c pthread_start_thread + 220 > 0x82fdf1a thread_start + 4 > > Any help would be appreciated. > > Please let me know if you need more info. > > Thanks, > > Ugo > > -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
